[ldv at altlinux.org: Re: experimentel Linux-PAM snapshot]

[Thorsten Kukuk]

----- Forwarded message from "Dmitry V. Levin" <ldv at altlinux.org> -----

Date: Fri, 19 Aug 2005 14:20:16 +0400
From: "Dmitry V. Levin" <ldv at altlinux.org>
To: Thorsten Kukuk <kukuk at suse.de>
Subject: Re: experimentel Linux-PAM snapshot

Hi,

On Wed, Aug 17, 2005 at 08:53:35PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 17, 2005 at 06:22:01PM +0200, Thorsten Kukuk wrote:
> > On Tue, Aug 09, Dmitry V. Levin wrote:
[...]
> > > + Deal with logging issue mentioned in CHANGELOG's TODO.
> > 
> > Somebody is working on that, but I don't know when the first patches
> > will be ready.
> 
> The problem is which direction to choose, i.e. "always openlog/closelog"
> or "never openlog/closelog"?
> 
> Well, I'll post my thoughts on this subject to the pam-list at .

Oops, looks like pam-list@ doesn't accept my messages: two my emails there
seems to be lost, and pam-list-owner@ also doesn't respond.

I've attached the message I sent to the list, with hope you could help to
deliver it to people potentially interested in dealing with the issue.


-- 
ldv

Date: Thu, 18 Aug 2005 16:44:38 +0400
From: "Dmitry V. Levin" <ldv at altlinux.org>
To: pam-list at redhat.com
Subject: Re: logging from PAM modules

Hi,

On Thu, Aug 31, 2000 at 10:02:12PM +0400, Michael Tokarev wrote:
> Andrew Morgan wrote:
> > Solar Designer wrote:
> > > I also agree that the callback pointer should be inside pamh.
> > 
> > So what does the final proposal look like? :)
> 
> Ok, prototype summary:
> [...]

The problem with logging from PAM modules was raised almost five years ago
(see https://www.redhat.com/archives/pam-list/2000-August/msg00291.html),
but nothing seems to be fixed so far.

In Linux-PAM-0.80, we have following situation:
- 15 modules use _pam_log(), defined in slightly different ways;
- 10 modules use _log_err(), with different prototypes;
- one module uses log_error();
- 3 modules use syslog() directly;
- approx. 24 of 34 modules use openlog()/closelog() calls for each logging
  function invocation, all the rest do not use openlog()/closelog().
- libpam uses _pam_system_log() for own needs, without
  openlog()/closelog() calls.

I suggest to cleanup this mess finally.

That is, either each module (or even _pam_dispatch_aux() itself) should
do openlog/closelog job, or no modules should care of it, just prepend
module-specific prefix to each message.  In either case, there are no
reason to re-invent the wheel in each module.

Personally I prefer second approach (no openlog/closelog job at all).

Unification process could be split in two stages.

At the first stage, all this logging zoo could be easily replaced with
common logging interface, for example:

void __attribute__((format(printf, 3, 0),nonnull(3)))
_pammodutil_vlog(const char *module_name, int priority,
                 const char *format, va_list args)
/* The _pammodutil_ prefix comes from convention for the internal pammodutil library */

and simple macro, e.g.
#define DEFINE_PAM_LOG(module) \
static void __attribute__((format(printf, 2, 3),nonnull(2))) \
_pam_log(int priority, const char *format, ...) \
{ \
       va_list args; \
       va_start(args, format); \
       _pammodutil_vlog((module), priority, format, args); \
       va_end(args); \
}

Implementation without _pam_log proxy function is also available but
it is a bit less portable.

At the second stage, all PAM modules should be reworked to provide
pam_handle_t parameter for new logging interface, like one suggested in
five years old proposal.

P.S. Current Linux-PAM _pam_log/_log_err functions do not use
__attribute__ yet.  Not surprisingly that simply added __attribute__
uncovered several format mistakes.  These obviously need to be fixed.

-- 
ldv






----- End forwarded message -----

-- 
Thorsten Kukuk         http://www.suse.de/~kukuk/      kukuk at suse.de
SUSE LINUX Products GmbH       Maxfeldstr. 5       D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B