bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug in openlog()


From: Petr Vandrovec
Subject: Re: bug in openlog()
Date: Fri, 21 Dec 2001 00:24:47 +0100

On 20 Dec 01 at 14:29, Ulrich Drepper wrote:
> Christopher Allen Wing <address@hidden> writes:
> 
> > 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.
> 
> The pointer must not become invalid.  Period.

It would be nice if we could have some calls to retrieve current openlog
settings - problem is that PAM modules writter documentation says that
your module should call openlog("your module name", ...) - but if
you do that, it works with login and other programs which call openlog
itself after PAM authentication succeeds. But some applications
(Cyrus IMAPD) call openlog _before_ they call PAM code - and so they 
die because of pam module was already unloaded from memory when imapd
tries to log some message - syslog interface still holds pointer to pam 
module .data section.

It is possible to workaround by invoking openlog(NULL, ...) or closelog()
at the end of PAM module, but in this case Cyrus IMAP logs messages as 
'syslog' instead of under 'imapd' name :-(

So yes, it is possible to add calls to openlog() to each program which 
uses PAM modules, but providing some infrastructure so that PAM could 
restore syslog environment on its exit will help a lot. Something like

int getlogsetting(const char** ident, int* option, int* facility)

                                            Thanks,
                                                Petr Vandrovec
                                                address@hidden
                                                



reply via email to

[Prev in Thread] Current Thread [Next in Thread]