On Sat, 2004-03-13 at 10:09, Sam Hartman wrote: > [Copies to me; I'm on debian-devel but very behind and don't really > have enough time to read it] > > > Bug #213566 is another complaint about how PAM handles logging. > Currently PAM_unix calls openlog in the pam library in an attempt to > make sure that PAM authentication messages are logged claiming to be > from the PAM service name (pam_unix) instead of from the application > or in cases of applications that do not call openlog, from unnamed > syslog lines. > > The submitter of this bug argued convincingly that calling openlog is > an inappropriate abstraction violation. Libraries should not modify > global state such as the syslog configuration. Modules that are > plugins to libraries especially should not do this. I agree here. In the report it is said that PAM handles this way: - PAM can allow modules (and the library itself) to log information using the syslog facility, and require applications to re-establish any application syslog settings after every call to libpam This is not acceptable, and places an inappropriate limit to application that use PAM. It is okay for _modules_ to restrict the use of syslog, but _not_ for an application. IMHO the real cause is a syslog design problem: instead of having one global 'instance', openlog() should return a handle, which has to be given to each syslog() call. But there is not much that can be done about that, unless someone volunteers to implement an alternative syslog() library. A much better way would be to require an application to provide a callback for logging - this way the application may decide to not use syslog at all but something different. Option #2 in the report log. This would also allow the library to give a name tag in the syslog line, to show where the message originated. > Sun has apparently also removed calls to openlog from their PAM > implementation. > > It is my intent to remove this call to openlog. Doing so may very > well change the format of messages logged by PAM application. This is > both a heads up and a chance for you to convince me I'm wrong. Although I agree with you on the problem, I think this should be really handled by upstream, otherwise you make it incompatible. Greetings, Oliver
Attachment:
signature.asc
Description: This is a digitally signed message part