Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.unix.wizards Subject: Re: anonymous ftp, and chroot Message-ID: <532@auspex.UUCP> Date: 28 Nov 88 19:06:10 GMT References: <3024@watale.waterloo.edu> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 28 >* It is my understanding that I can open any file, do a chroot, and >still have access to that file until I close it (even if it lies "above" >the new root directory). Does this statement not hold true for UNIX >domain sockets like /dev/log? No, if I read the 4.3BSD code correctly, it doesn't. For one thing, you don't open UNIX-domain sockets (fixed in 4.4BSD?); you do a "socket" call that creates a socket that refers to the UNIX-domain protocol/address family in general, not to some particular "address" in that family, and then either do a "connect" call to bind it to a particular address, or specify the address in a "sendto" call. That's the point at which the "address" - which, in the UNIX-domain case, is the pathname of a file such as "/dev/log" - is interpreted, and if that happens after the "chroot", you lose. >Assuming that there really is a problem, and I'm not just being >dense, how can I fix in.ftpd to properly log messages after calling chroot? It's "syslog" that needs fixing; it should do a "connect" in "openlog", right after it's created the socket. Then just make sure "in.ftpd" does an "openlog" before doing the "chroot". In fact, the 4.3-tahoe "openlog" does precisely that; if the "connect" fails, it notes that it is not connected, and tries to do a "connect" when it does a "syslog". (The intent behind that is presumably so that you can call "openlog" before "syslogd" has started up and created the "/dev/log" socket, and not have it fail, just have it retry later when "syslogd" may be up and running.)