[ On Wednesday, August 27, 2003 at 19:12:41 (-0700), Bill Studenmund wrote: ]
> Subject: Re: BSD Authentication 
>
> > But that feature is not really necessary -- it's only used that way
> > now to implement some very poorly designed hacks.
> 
> Greg, why do you always interject derogatory language into discussions? It
> only serves to make folks disregard you as a coot.
> 
> And as for what AFS is doing being a "hack," how about you examine the
> problem some?

I have in fact looked rather closely at both the way AFS authentications
work and at the excuses used to justify PAM for that application.

I've also looked very closely at the reasons given for designing PAM in
the way that it has been designed.

All I've seen on both fronts are some very poorly designed hacks that
were intended only to meet the immediate needs of the very few.  Much of
the literature I've read says very much the same.

Shall we all stop labeling things for what they are and stuff our
collective heads down into the sand so that it all looks the same no
matter what it is?!?!?!?  If that's what you'd rather do then I must
somehow have been transported into an alternate universe!  How do I get
back to where I was?

> AFS is essentially implementing an in-kernel credential cache. As AFS is a
> file system, and thus lives in the kernel, and cares very much (perhapse
> anally-much) about security, this is a very sensible state of affairs.

Those parts of AFS are not at question -- what's at question is its
extremely poorly thought out interface into the rest of the Unix
security model.  If you want to use AFS in a Unix system and if you hope
the resulting merge to be secure, it really would help if AFS could work
with the Unix security model instead of against it.  Fortunately the way
it has been done by some in the past is not the only way it can be, and
it seems already has been, done.

To me it really does seem as if all the PAM fans are trying to justify
the need for using PAM by pointing only at things that are in the end
completely unfounded.

It also seems as though many of the few folks who do need to use the one
concrete example application that's been claimed to pose a problem for
BSD Auth, i.e. AFS, have been so close to the problem and the one
solution they think they have now that they've been unable to step back
and re-evaluate their true requirements and look for more elegant
solutions.

Finally let's try to look at the numbers scientifically once more.  Even
if we count all the people who think they might ever in the forseable
future be able to make good use of AFS in true production environments
where they now or may someday use NetBSD, are there enough of them to
justify tightly integrating a technology that many of the rest of us
would rather never have seen the light of day?  Indeed is AFS itself
ever going to be integrated directly into NetBSD as a first rate
supported feature (e.g. like NFS now is)?  Are there any other
commercial non-source PAM modules that really need to be run in a
tightly integrated environment and which cannot be made usable from an
external BSD Auth wrapper?  Even if we count all of the peoplw tho think
they might ever in the forseable future be able to make good use of
commercial non-source PAM modules in true production environments where
they now or may someday use NetBSD, are there enough of them to justify
tightly integrating PAM into the main NetBSD release as a fully
supported first-rate feature?  Are not those users of commercial
non-source PAM modules also willing to pay an additional fee to obtain
and support the maintenance of a customized version of NetBSD where PAM
has been tightly integrated to replace a native BSD Auth?  Are those
users of commercial non-source PAM modules not willing to pay to have
BSD Auth versions of their special authenticators written and maintained
so that they can use them in all systems where BSD Auth is natively
available?

BTW, it seems to me as though everyone who has spoken up repeatedly in
favour of having BSD Auth integrated into NetBSD is actually willing and
able and eager to help direclty in making it happen, and the sooner the
better.  Why don't those of you who are developers think about how you
might make use of these additional volunteer resources so that we can
get this integration done.  Then maybe instead of just discussing the
whole issue over and over to death we'll then have time to work directly
on the other issues that are faced by with the likes of AFS and
commercial non-source PAM modules.

-- 
						Greg A. Woods

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