anonymous ftp, and chroot

[Guy Harris]

>* 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.)