anonymous ftp, and chroot

[der Mouse]

In article <3024 at watale.waterloo.edu>, daemon at watale.waterloo.edu (Watale's Little Helper) writes:
> I have been having trouble trying to get in.ftpd to record all
> anonymous ftp activity.  I don't quite understand why, but the
> problem seems to be caused by the chroot call.

> A trace of in.ftpd shows the following:
[...]
> chroot ("/usr/ftp") = 0
[...]
> [crash, and burn time]
> sendto (3, "<31>Nov 25 22:32:07 ftpd[6019]: ".., 42, 0, 0xd4e8, 16) = -1
> ENOENT (No such file or directory)

Aha.  That's a sendto(), which passes the address ("/dev/log") at the
time of the sendto(), which is after the chroot.  And after the chroot,
there is no /dev/log.  And even if there were, it wouldn't be the one
syslogd is listening to.  Normally, syslog() would then write it to the
console, but /dev/console doesn't exist either.

What we need is a syslogd that allows tcp connections, or perhaps a
connect() on a datagram socket (I think this might work now).

> It seems that altering the root directory somehow messes up access to
> /dev/log.  I suppose the obvious answer is that /dev/log is no longer
> accessible once the chroot("/usr/ftp") takes effect.

True enough.  The path /dev/log no longer points to what it has to
point to - the inode that's got syslogd's socket attached to it.

> But there must be more to it than that, because /dev/log is opened
> before the root directory is changed*.

/dev/log isn't opened; you can't open sockets[%].  The filesystem is
traversed for /dev/log each time you call syslog() - this is done in
the sendto() kernel implementation.

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

This is perfectly true.

> Does this statement not hold true for UNIX domain sockets like
> /dev/log?  And if so, why?

It does hold true; it's just that what's being done (sendto) doesn't
open /dev/log once and then use it.  It's more nearly equivalent to
opening /dev/log, sending, and closing, all within the sendto().

> 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?

The proper fix is to rework syslog() and syslogd so they can be made to
work even after the client chroot()s.  This is probably beyond most
people.  I don't see any simple fix.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu