[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: An interference between PAM and other libraries [was: Linux-PAM and syslog]
- From: Andrew Morgan <morgan transmeta com>
- To: pam-list redhat com
- Subject: Re: An interference between PAM and other libraries [was: Linux-PAM and syslog]
- Date: Mon, 30 Mar 1998 22:42:54 -0800
A lot of people have written a lot of stuff:
> [stuff deleted, but hopefully represented below]
A number of things have happened with the development of Linux PAM.
We have gone from the existence of a document ("the" RFC) to having a
completely implemented version of PAM that includes some features not
present in the original "definition" and had the opportunity to point
out some failings of the original proposed "standard".
Similarly, the original authors of PAM who worked for Sun have
progressed to get their standard absorbed into a greater scheme
(XSSO). My understanding of this endeavor is that no sooner did Sun
share the PAM idea than it got bogged down by committee, its Sun
maintainers left for better jobs and the "official" PAM concept has
ground to an halt -- far short of its potential.
PAM is quite a revolutionary way of programming. Its value is two
fold: it has placed a great deal of control in the hands of people
that run and maintain their computer systems (something that I have
only ever received complementary email about :^); its second value has
been to explore the notion of pluggability as a workable model for
(security) programming. It is this latter point that this thread (and
its predecessor) are all about. In other words how do we resolve the
problems we encounter when we graft a new way of programming onto an
old set of applications?
There are two competing assumptions being championed: PAM is "just" a
library and should be transparent to any application that uses it; and
PAM is an API with a specification and a calling convention and any
programmer that wants to use it should play by the rules.
As with most conflicts of opinions, both points of view have some
merit and both points of view should be explored.
The problem that has initiated the current debate is what to do about
syslog() and its friends, which (everyone basically agrees) represent
a poorly designed interface for logging to a system file when one
considers either modular or threaded programming models. The argument
has been put forward that an application should not expect its
implicit connection to a filehandle (syslog) to be interfered with by
a PAM module - especially when this leads to seg-faulting!!
One solution to this problem is to demand that the application be PAM
"complient" and actively expect libc to get rewired during a libpam
call. It is possible that this is the only safe way for an PAM
supporting application to be written, since we have no control over
what some module (written at some future date) will eventually want to
do. This is a bitter pill to swallow when trying to quickly port
applications to the PAM way of programming and places an extremely
large burdon on the application developer to anticipate all of the
poor programming that may be going on in "standard" system libraries.
Another solution is to insist that PAM modules do not do things that
are likely to upset "common" applications. In general, this is a hard
thing to define. In the case of syslog, for example, it is proposed
that the module not be allowed to execute openlog() and or closelog()
since these functions have very bad effects on an application that is
intending to use syslog().
It can be argued that limiting PAM modules to using syslog() is not
really a scalable solution either, since any application that calls
closelog() and then calls libpam will likely segfault when a module
calls syslog(). Said another way, applications that want to call
openlog() twice (perhaps logging with a different "option") will cause
havoc with the "normal" behvior of the modules.
The only reasonable way to proceed is to make both modules and
applications as transparent to each other's environment as possible.
Syslog and functions like it are bad, bad and bad again and we must
insulate all of the players PAM from it...
At this point, I should own up (I remembered it over the weekend) and
admit that libpam suffers from this syslog problem. It only strikes
in cases that libpam experiences some sort of configuration error.
[It is all with a function in libpam/pam_misc.c (_pam_log_error().]
If we cannot agree that an application has no business calling syslog
and leaving the log open, this is something we need to fix. It is
also something that breaks libpam from the point of threaded
programming so libpam is indeed currently broken.
How to fix it? This is the subject of another (shorter) email.
The other lesson to be drawn from this discussion is the importance of
having a standard reference when trying to resolve issues of this
nature. It has been claimed that there is "no standard" solution to
this problem. The fact is that the Linux-PAM documentation does
indicate a resolution. Another fact is that this document carries no
weight. The original DCE-RFC has nothing to say on this issue, the
single XSSO draft is less than useful. Worse still, the original PAM
developers are no longer available for comment.
I am more convinced than ever that we need to write an RFC that builds
in all of our experiences so far. Without something like this, PAM is
destined to not be a viable approach to maintaining any reliable form
[Date Prev][Date Next] [Thread Prev][Thread Next]