syslog + chroot + ftpd

[Dan Bernstein]

In article <104489 at convex.convex.com> tchrist at convex.COM (Tom Christiansen) writes:
> In article <11477:Jul3018:50:4290 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In what conceivable way can syslog() do better than stderr? 
> Syslogd(8) from BSD4.3 is a highly useful general purpose error
> handling facility.

Yeah, and what do you plan to do with syslog-based systems when people
find a need for more general error logging? How 'bout flags like ``this
is a disk space error, save me!'' or ``I/O? Something wrong with the
disk?''? Or extra parameters like ``I was invoked with the following
arguments''? Or the uid or the gid or part of the environment?

Have you really been deluded into thinking that syslog is sufficiently
flexible to handle everything that good error logging needs?

>     * It allows the sysmgr to centrally control what kinds of error
>       messages he's interested in,

The same is true if you pipe errors to a program that reads from a
central configuration file. In fact, syslog is just such a program. How
could you lose flexibility by *allowing* noncentral control?

>     * You don't have to constantly re-invent logging code.

Oh, yeah, right. Like it's so much effort to fprintf to stderr. This
reflects another problem with syslog: it doesn't let the user take
advantage (?) of some of its features (?) without swallowing the entire
mechanism.

> You don't
>       have to be careful about opens on the console blocking due to
>       control-s or whatnot and hanging YOUR program.

Which reminds me of yet another problem with syslog. What happens when
you flood syslogd with errors? In a correct implementation, either
syslog() blocks, or syslogd loses messages. In the first case, people
like you have been lying to the programmer, who believes that syslog()
will never block (except with exiting children around); the deluded
masses then never even realize there could be security and efficiency
problems. In the second case, you've opened up a huge security hole.
Even denial of service is bad enough: I don't want to risk losing errors
just because twenty programs decide to use syslog() at once.

Which case is it?

At least when I'm writing criticial errors to a file I'll check for the
write() failing. Name one program that checks syslog()'s return code.
(Does it even have a return code?)

>     * You don't have to remember to properly redirect standard error when 
>       you start or restart a daemon.

This seems to be a major issue with you and Jon. Fine: foo by default
reopens stderr as /dev/log. If you say foo -2, it'll send errors to
stderr instead. All daemons adopt this convention. Happy?

> In summary, just writing to stderr is a practice fraught with the danger
> of doing it wrong, does not permit easy and fine-grained configurability.

Ahahahahaha. Good joke.

> Syslog can be used by all forms of programs, encourages code sharing and a
> common interface, and allows you to easily write summarization scripts.

The same is true of stderr, except that syslog is less flexible and
won't expand so easily when people want to add information to their
error messages.

> Stderr writing is a bad practice that should shrivel up and die.

syslog is an insecure, poorly implemented model that will not handle
future needs.

> I guess this is why we need a comp.unix.admin newsgroup.

It is an appropriate topic for comp.unix.admin.

---Dan