[ On Thursday, September 11, 2003 at 08:34:51 (-0700), Greywolf wrote: ]
> Subject: Re: BSD auth for NetBSD
>
> I'm not a big fan of PAM, but I see what needs to be accomplished.
> The light went on as soon as I fully understood the difference between
> authentication (which is easy and is a read-only operation) and
> authorisation (which is the write-half of the process, which is trickier
> because it needs to be able to modify the credentials of the process).
> 
> As long as we focus only on authentication, the requirements for one,
> the other, or both are not as clear.  Once we integrate authorisation
> into the requirements, it becomes clearer as to why different solutions
> are desired.

Yeah but what I think you may be missing is that authorisation happens
at the filesystem level, not at the application level.  Nothing really
needs "pluggable" or otherwise runtime configurable authorisation hooks.

For example the AFS authorisation hooks go deep in the associated
filesystem code in the kernel and are not "configurable" per se.  They
work by examining credentials also stored deep in the kernel by the
authenticator.  The only trick is in associating the stored credentials
with the process group, and so long as you let a privileged process, or
a child process, store that association, and so long as you store them
in the right place in the process and if necessary you modify fork() and
exec() so that they copy and preserve those associations, then you've
solved the problem.

> We need to accept the following:
> 
> BSD Auth / PAM won't work 100%.

It will.  Really.  It just needs a tiny bit of thinking outside the box
the PAM/AFS folks have built so tightly around their minds, as well as
acceptance from anyone wanting binary-PAM support that they/we can
indeed make their modules work through a BSD Auth proxy authenticator.

It's really not a very difficult problem conceptually.  I've already
outlined almost all the things that can be done to solve these problems
in the context of BSD Auth.  There is no fundamental and real roadblock
to making PAM work as an authenticator module for BSD Auth.  None
whatsoever.  All the proposed examples are smokescreens that blow away
in the wind after re-analyzing their underlying true requirements.

> PAM / BSD Auth won't work 100%.

Using BSD Auth authenicators via PAM Won't ever work, period.  The whole
idea of BSD Auth via PAM flies in the very face of everything BSD Auth
stands for from beginning to end.  What a laugh of stupid design such a
monstrosity would be!

> Static lookups won't work 100%.
> Switch lookups won't work 100%.
> 
> Static and switch can share code; BSD Auth and PAM probably can't, even
> though there may be similar methodology involved.

I'm not sure what you mean there....  I don't see any problem so long as
someone doesn't think they need static linked apps with PAM.  One could
theoretically fool PAM in to thinking it's doing dynamic loading when
really it's just using a static linked copy of the module, but that's
really not the point, is it?

> The solution is to implement BSD Auth and PAM separately, with some
> overlap possible once all is said and done, but make sure they
> each work as they need to individually.

Indeed, which is basically what those of use desiring BSD Auth _first_
have all been saying all along too.

> A totally different issue involves allowing a mix of static/dynamic
> linking.

Only if you also want PAM which seems to require dynamic linking as part
of its core specifications.  I don't ever want PAM, so I don't care.  :-)

> For i386 and possibly SPARC, sure; what about the other CPU architectures
> that we support?  They're dead in the water.  I will grant that this is
> an orthogonal issue, but it's something to consider.  (Not that we could
> do much about it except possibly write an i386 emulation layer (um...ew?)).

Huh?  It's an irrelevant issue!  :-)

(note that proprietary binary-only PAM modules will be supported on
whatever hardware platforms the hardware vendors and software vendors
and the market agree are viable to be supported.  E.g. PA-RISC seems to
be supported by some now, and Alpha probably is too.  Note also they'll
all require syscall emulation for the "native" OS too, anyway.)

> The same problem might exist WRT BSD Auth, except I haven't heard of too
> many companies writing BSD Auth modules.

That's because they're too trivially simple to worry about.  A junior
baby sys-admin could write one as a wrapper around any existing
command-line usable authentication tool with one hand tied behind his
back and the other stuck in his ear and with one eye closed, provided
his nose or elbow wasn't too big that he'd be hitting too many keys at a
time!

-- 
						Greg A. Woods

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