[Top][All Lists]
[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