I mostly agree with what you say, except for one detail:
> 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.
This (opening /dev/log from within libpam) is, in my opinion, a bad
idea. The reason for this is that we add yet another package
(Linux-PAM) that needs to be compatible with the system's logging
protocol. Yes, it has remained constant for many years, but this is
changing. We already have datagram and stream sockets, and we will
likely/hopefully have credential passing soon.
I think the application should register a callback function with
libpam. That function will accept the module and service names and
the format string plus any number of arguments as passed from the
module. There should also be a default function provided within
libpam itself. The call chain might look like:
(module) -> /* in module */
pam_log(format, ...) -> /* in libpam */
appl_log(module, service, format, ...) -> /* in application */
syslog(LOG_AUTH, format, ...) /* in application */
Signed,
Solar Designer
