syslog + chroot + ftpd

[Dan Bernstein]

In article <1990Jul29.202447.11548 at athena.mit.edu>
jik at athena.mit.edu (Jonathan I. Kamens) writes [ trimmed & reordered ]:
> 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.
>   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().

But it is the only solution for someone who doesn't want to muck with
his libraries, or for someone without source code, or for someone who
doesn't want to spend half an hour working bugs out of new BSD stuff.
In other words, theory is nice, but I think Luis wanted practice.

> |> If error messages were piped out stderr to an error-handling program,
> |> these problems would never happen.
>   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.

Say what? I believe that good old stderr is a much better model than
syslog(), and I supported my assertion by pointing out that it would
solve problems like this.

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

Now you're making unsupported assertions. In what conceivable way can
syslog() do better than stderr? We could settle on some conventions for
standard error message formats, then make programs to interpret them in
different ways. This is obviously much more general and flexible than
syslog: you can change what's done with a program's errors simply by
editing a command line. You don't have to futz with syslogd, edit any
configuration files, stick new 'n' important special files into your
system, or conform to the facility-level-file model of error handling.
In the future we'll get backward compatibility trivially, rather than by
leaving obsolete daemons, /dev/log, and similar clutter around.

---Dan