bug in openlog()

[Christopher Allen Wing]

Hello,

the syslog routines in glibc have a behavior quirk (inherited from the
original BSD code) that can lead to crashes or other bad things happening
under certain conditions.

The openlog() library function:

        void openlog( char *ident, int option, int  facility)

when given a non-NULL 'ident' argument, retains the pointer you give it,
and uses it to format all subsequent syslog output.

The problem is that if the pointer becomes invalid for some reason, or if
the string is overwritten, future syslog output will be corrupted, or the
program might crash.

In particular, I have observed crashes when using Linux PAM modules that
call openlog() and generate their own syslog output. These modules call
openlog() using a pointer to a string in the module's data segment. After
PAM is finished, the PAM modules are munmap()ed and the pointer becomes
invalid. Future syslog() calls by the program that called PAM result in a
crash.


It is worth pointing out that this behavior (openlog() holding onto the
pointer you give it) is not documented in the glibc info pages, nor in
Andries Brouwer's complimentary set of man pages included on most Linux
systems.

Since I don't see any precedent or standard that we need to apply to in
this case, I recommend that we make openlog() copy the string and use the
copy internally.


Here is my proposal for a patch:

http://www.engin.umich.edu/caen/systems/Linux/code/patches/glibc-2.2.4-syslog.diff

Note that this patch is untested (hence 'proposal'). Also, it uses
strdup() and thus allocates memory at runtime. If this is undesirable for
syslog use I can change it, but it won't result in anything fatal.


Thanks,

Chris Wing
address@hidden