syslog + chroot + ftpd

[Jonathan I. Kamens]

In article <LUIS.90Jul27181155 at lutetia.rice.edu>, luis at lutetia.rice.edu
(Luis Soltero) writes:
|> has anyone noticed that syslog stops logging when ftpd logs in an
|> anonymous ftp user?  i have tracked the problem to the chroot system
|> call. prior to chroot() syslog works as advertized. once the
chroot()
|> is executed inside tftpd, however, syslog calls no longer get
|> recorded. 

In article <3787 at auspex.auspex.com>, guy at auspex.auspex.com (Guy Harris)
writes:
|> The 4.3BSD "syslog()" (as appears in SunOS 4.0, among other systems)
|> connects to "syslogd" using a UNIX-domain socket.  Do a "chroot()",
and
|> that UNIX-domain socket may no longer be accessible....

And finally, In article <29159:Jul2820:23:5290 at kramden.acf.nyu.edu>,
brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
|> syslog's poor model has ftp writing to a UNIX-domain socket in the
|> filesystem. Naturally, ftp can't find the file after it chroots. Try
|> hardlinking in a new /dev/log (I think) below ftp's home directory.
|> 
|> If error messages were piped out stderr to an error-handling
program,
|> these problems would never happen.

  Both Guy and Dan are correct in essence about the cause of the
problem, which is (in more detail) that when the 4.3BSD syslog() sends
messages to /dev/log by doing a sendto() on an unconnected socket,
rather than doing connect() when openlog() is called so that the program
has an idea of where messages should be sent, even after a chroot().

  Dan's first suggested solution will work for the special case of
ftpd's chroot() for anonymous ftp, but will not work for the general
case of other programs which do a chroot().

  The BSD networking release sources (and thus, I assume, the 4.4BSD
sources) solve this problem by doing a connect() to /dev/log the first
time logging is done (or when openlog() is called), so that the program
knows where to send messages even after the chroot().  If you can get
your hands on this version of the syslog library code (it may be
available on uunet.uu.net, or, if you have a BSD source license, you
should be able to get it from BSD), you can install it in your C library
and relink ftpd to get rid of the problem.

  Dan's second suggested solution is, as is somewhat usual for Dan :-),
a condemnation of a particular feature of Unix simply because he
believes that it's "the wrong way to do things."  Whether or not said
condemnation is correct, it holds little weight in my mind when
presented as an unsupported assertion.  In any case, I disagree with it,
and think that the syslog system is useful in ways that "an
error-handling program" on stderr would not be.

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710