anonymous FTP logging (SUMMARY)

From: Pete Cottrell (
Date: Wed Jun 19 1991 - 18:29:50 CDT

        Sorry for the delay in responding - based on the mail I got, I know
that a lot of people are interested in a summary. Better late than never...
        My original query:
        I think this might have been discussed before, but I'm not sure.
Due to some continuing annoying activity that I need to monitor more
closely, I have been putting more logging into ftpd (or in SunOS, in.ftpd).
I haven't had any problems on my VAXen running our highly bastardized
version of 4.3BSD, but I'm having problems with anonymous ftp logging
under SunOS 4.1. Once ftpd does the chroot() to ~ftp, I get no more
logging. More specifically, the sendto()s bomb out with ENOENT, which
seems to make sense, since they are connected to /dev/log, and there
is no ~ftp/dev/log file.
        However, the socket is opened and successfully written to
before the chroot(), so I don't see that the chroot() should make it fail.
This is essentially the same code that is running successfully on the VAXen.
Thinking that it might be a problem with using a different instance of the
shared libc after the chroot(), I tried a version compiled statically, but
have the same problem.
        I've thought about doing a closelog() before the chroot() and then
another openlog() afterwards, but I don't think that'll help, since
~ftp/dev/log won't exist to connect to.
        I'd appreciate any thoughts you all might have on this. Thanks.

        The responses were varied; some told me that the problem was due
to a kernel bug, some told me that Sun's version was the problem. The
latter is true, the former is false. Tim Smith kindly provided me with
a summary of the same question from the sun-nets mailing list.
        The overwhelming answer I got was that the problem was that
syslog() uses Unix domain datagram sockets, which says to them that
no connection is made:
>Since /dev/log is a datagram socket, there is no connection; even if
>openlog() does a connect(), that only fixes the address to send to,
>which will be reinterpreted for each sendto().
        The suggested fix was to change syslog to use tcp/udp sockets,
which several people had done. Such a version of syslog() supposedly
exists in the ftp directories.
        The answer is only partially correct, since as I stated in my
original message, I had successfully added logging of anonymous ftp
sessions to my BSD (and also Encore Umax 4.0) versions. The syslog()s on each
of these systems also use Unix domain sockets. The precise answer was sent
in by Steve Bellovin (
>Syslog() uses a datagram socket, so there's no connection established
>simply by keeping the socket open. Some folks have modified the
>code to support a connected option.
        Bingo! The BSD and Encore versions do a connect() after opening the
Unix domain socket and then do write() ( or send(), in the case of the
Encore). Therefore, the address is bound before the chroot() and no
problems occur. The Sun version, on the other hand, merely opens a socket
and then does sendto()s. After the chroot(), each sendto() fails because
the destination address does not exist under the new root. Steve Miller
of UMIACS ( also pointed this out to me when I failed
to pick up on it the first time.
        Steve Bellovin and Andy Sherman both suggested clever tricks for
getting around the problem without modifying anything:
>What's been done here is a clever hack: create /dev/log as a symlink to
>/usr/ftp/dev/log. Then fire up syslogd with the (undocumented) option

>My solution was to put the named socket in /home/ftp/dev/ and plant
>a symbolic link in /dev for the benefit of everybody *but* FTP.
>It works.

        I also received pointers to several versions of ftpd that have
already been enhanced:
>My simple answer is to junk Sun's ftpd :-). I use a version that is
>available on (pub/4.3/ftpd-sirius.tar.Z) that will
>do all you want and more. It is based on the BSD 4.3 tahoe version (I
>think) and I will be porting my mods to the Reno version RSN.

>The machine hiding behind is a Sun-4/260S running
>SunOS 4.0.3 so hopefully you should just be able to compile it and run

>I'd suggest getting a copy of the code they're running at
>; it has extensive logging, some amount of access
>control, and a number of bug fixes. wuarchive manages to use up about
>10% of the NSFnet bandwidth doing anonymous FTP with it so I'd say
>it's probably pretty stable.

>The contact at Wash U. is Chris Myers (; he'd
>be able to tell you exactly what code to pick up.

        The sun-nets summary points to another version of ftpd, this one
available from Brendan Kehoe of Widener University:
>I've hacked on ftpd to do logging of where the connection's from &
>what username they put. It also allows restriction of hours to 6pm-6am
>if needed. It doesnt log what files they get (or at least I've never
>given it a try). You're welcome to a copy if ya want. It's on
> [] in pub/unix/widener.ftpd.tar.Z.
> Brendan Kehoe - Widener Sun Network Manager -

Quick synopsis:
        Sun's version of syslog() can be fixed by changing it so that it
does a connect() after doing the socket(), and by changing the snedto()s
to write()s. Another option is to change syslog() so that it uses tcp/udp
sockets instead of Unix domain sockets. A third clever trick is to make
/dev/log be a symlink to ~ftp/dev/log and to then make syslogd create
        Several logging versions of ftpd are available at various named
places around the net.

        As usual, the list is great. Pardon my delay in summarizing.
Thanks to:
        Jim Guyton <> (Ed Vielmetti)
        tgsmith@East.Sun.COM (Timothy G. Smith) (Kurt J. Lidl) (Mark Plotnick) (Kerry Duke)
        Gordon -v Galligher <oconnor!>
        Julian Bradfield <>
        Steve Miller <> (down two floors and several
                doors, or in my office several times a day)


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT