[ On , September 26, 2002 at 14:36:58 (+0200), Love wrote: ]
> Subject: Re:PAM 
>
> 
> First since Greg A. Woods think that am a pro-PAM person, I'm not. I don't
> care if you use PAM, SIA, bsd-auth or men with three lingon berries on
> their shoulder to solve the problem. I'm a pro-AFS person, being a author
> of a AFS implementation kind hints that I am.

However you do seem to think PAM is the better panacea for AFS issues,
and if that is so then perhaps you'll understand my confusion!  ;-)

> > Indeed in Watson's API there isn't a way to modify/assign the PAG for
> > another proces, but that's a pretty trivial and obvious modification to
> > make.  Take off your PAM blinders!  ;-)
> 
> There is a lot of security problems with allowing that, like how do you do
> that when you are in securelevel > 0.

No, there are no additional security problems with that scheme,
especially if it's limited to the child process (i.e. the syscall only
modifies the parent process), especially when that child process is
running as the superuser, though of course any superuser process could
be authorised to modify any other process under controlled and specified
circumstances.  The point of designing a proper kernel syscall API to do
this is to help the OS kernel limit what any superuser process can do,
i.e. to reduce the capabilities and privileges of the superuser.

> And it require me to modify all applications, same with Douglas Engert
> proposal. If I use PAM it doesn't.

No, certainly not, not even for all the other surrounding details, at
least no when you have any decent intermediate API, such as NetBSD's
nsswitch (though some minor extensions to our implementation are still
desirable, and perhaps even necessary).

> I'm not looking at the problem from PAM good or not direction, I'm looking
> at it on the is this good for AFS direction.

AFS certainly doesn't need PAM in order that it be used in any Unix, and
especially not in any open source unix.

> Really, I would like to have both a bsd-auth (exec-chain ?) like PAM module
> so my xlock can verify with my keyfile when I'm using Kerberos.

I think you're confusing concepts here.  PAM is simply a "standard" API
that relies specifically on dynamic binding to enable applications
wishing to do authentication and authorisation (A&A) be able to do so
with methods that were unspecified at the time those applications were
designed and built.

The primary reason PAM was designed was to give proprietary OS vendors
the ability to provide hooks into their A&A applications such that users
could implement and use A&A mechanisms that may not even have been
thought of at the time the OS was released.  Such hooks, when
implemented in shared libraries or dynamically loaded object modules
allow the OS vendor to keep the source code for their applications
secret and to only ship binaries.  This is of course completely and
totally unnecessary in any open source system since the user has full
access to all of the source code and they can hook in any module at any
time without needing to use dynamically loaded code.

Any decent API with similar capabilities would allow the user to hook
such new A&A modules into one place without having to modify all A&A
applications (i.e. applications can still be designed by the open source
vendor without knowing what authentication methods will be used or even
thought of in the future).

The executing of separate programs, possibly as child processes, or
possibly in "chains", or maybe even in a client/server design (eg. Cyrus
saslauthd), is an _alternative_ way to get the same kind of run-time
flexibility, and of course if such a mechanism is wrapped in a decent
API (eg. perhaps BSD-Auth, or Cyrus SASL), then similar design-time
flexibility is also achieved.

PAM suffers in that it _requires_ (by its own design) the use of dynamic
runtime object code loading, which is itself fraught with all kinds of
issues, including _many_ security related issues.  If "pluggability"
were not the primary reason for PAM -- i.e. if it were a simple wrapper
library like nsswitch as the latter is currently in NetBSD -- then it
might be much more widely useful (though in the face of nsswitch, I've
got to wonder which API would be easier to use!).

Note though that use of separate programs for the specific purposes of
authentication and authorisation wins enormously over both nsswitch and
PAM, especially on Unix, and especially when written in C, since it
provides for the separation of privileges.  PAM code must all run as
root, which means the process which dynamically loads the PAM module
must run as root.  The same goes for nsswitch of course, as it would if
all the PAM modules were statically linked into the applications using
them.

> Summery: you think that we AFS users need to modify all applications to do
> afs_setpag where we think its needed. That sucks.

No, you're still not thinking through all the proper and necessary
steps.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>