bug-glibc
[Top][All Lists]
Advanced

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

Re: bug in openlog()


From: Christopher Allen Wing
Subject: Re: bug in openlog()
Date: Fri, 21 Dec 2001 18:03:17 -0500 (EST)

Petr:

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

Yep, that's what happened to me. (Out of curiosity, do you know how PAM
behaves on Solaris? I think that it might not unload the shared objects
after PAM ends, unlike Linux-PAM, because I am using the same PAM module
there and I don't see any crashes)

> 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 :-(

Really, the problem is that the (BSD) syslog interface is pretty hopeless.
I guess PAM should have used its own logging interface (sending to
/dev/log directly) rather than risk messing around with openlog().

> 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 :-(

Hmm, that's odd. Under glibc 2.1 and 2.2 at least, closelog() resets the
string to argv[0], which should be 'imapd', I'd think.
Solaris behaves the same way, HP-UX does not. (closelog() doesn't reset
the ident pointer)

> So yes, it is possible to add calls to openlog() to each program which
> ses 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)

Hmm, I think that a better way to do this would be:


struct log_handle *openlogx(char *ident, int option, int facility)

handle = openlogx("my_pam_module", ...);

syslogx(handle, "blah");

closelogx(handle);


Then, you could have more than one independent thread of logging going on
at a time. (useful for threaded programs or stuff like PAM modules)

But really, a better approach to logging needs to be written from scratch,
to address other problems like:

        - syslog is insecure on a multi-user machine
        - syslog is (typically) insecure over the network
        - syslog is unreliable

and in the future syslog can plug into that.


For now, Ulrich is right: we need to preserve existing behavior.


Thanks,

Chris Wing
address@hidden




reply via email to

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