Solar Designer wrote:
>
> BTW, I am not sure whether it is appropriate to do syslog() and
> especially openlog()/closelog() from PAM modules, even though lots of
> them do so now.
>
> openlog() messes up the existing syslogging setup an application
> could have made. Currently, applications don't do a second call to
> openlog() after authentication. The reason we don't get weird log
> entries because of this is that most of the syslogging done by PAM
> modules is to report a failure, so the application simply doesn't
> continue.
Wooh! This is the same question that I wanted to ask here too! :)
Syslogging is a mess currently in pam, especially in application's
point of view -- currently I saw comments in many apps saying
something like:
...
pam_authentificate(...)
/* Linux-PAM closes syslog(), and here is a workaround for this
while people at Linux-PAM will close their bugs: */
openlog("app", LOG_xxx, LOG_xxx);
Doh! :(
Really it will be nice to have our own implementation of syslog
support.
> It's probably a matter of taste, but I don't like the modules using
> their name as the syslog ident. I think log entries like:
>
> Aug 21 07:30:36 hostname service[PID]: module: message
>
> would be more consistent. (The "service[PID]" part depends on how
> the application has initialized syslog.) The only problem I see with
> this is that it's not possible to determine whether the application
> has done an openlog() call at all.
There probably should be a standard format for this, and modules
should _not_ pass their names to logging routine, see below.
>
> Maybe libpam should provide its own logging interface which could be
> overriden from applications. Then the module name would be available
> separately from the string being logged, and the logging function
> could decide whether it uses it as syslog ident or as a part of the
> message. The default logging function provided in libpam could check
> a global variable to find out whether it needs to call openlog(), etc.
current syslog() interface is very limited in capabilities, but
it was designed this way -- to made things simple.
There is not "channel" concept (or "stream", "file" etc) that
is obtained from openlog() and passed to every syslog() call
(btw, there can be the "current" channel contept that can be
switched using some "setlog()" routine in addition to
{open,sys,close}log()). So, if pam will be able to do things
itself, providing pam_[sys]log() routine with appropriate
arguments (wow, pam should know what module currently executes,
and what service currently serviced, so that will be no need to
pass additional parameters and obtain them, and messages
can be made standartized) that will open it's own syslog
filedescriptor to /dev/log and will not mess with app's opened log.
The question remains is when to close it.
But it is ok to reopen it each time (I think :) as currently all
code does, since it it not time-resource-critical part of the system.
BTW, syslog implementation is very simple.
I don't see a need to have custom logging destination choosen by
application, but who knows.
Regards,
Michael.
P.S. Request For Comments was in the pam documentation for a long
time now.
