Subject: Re: PAM
To: None <email@example.com>
From: Ken Hornstein <firstname.lastname@example.org>
Date: 09/25/2002 11:28:19
>I haven't seen the code; if you can point me at it, I can offer a more
>informed opinion. But I have trouble believing that it's all that
>difficult to use curproc->p_pptr instead of curproc. (Actually, I
>think that if it is, the code is in severe need of a rewrite anyway,
>but that's neither here nor there for the immediate point.)
Fair enough; the whole AFS implementation is at http://www.openafs.org;
the kernel cache manager implementation is in the "afs" directory of
the source tree.
>I don't agree that setting an environment variable is "teaching the
>upper layer about each authentication system"; setting an environment
>variable is a sufficiently generic and common thing that it's
>reasonable to put a facility for it into the protocol. (Indeed, one
>could argue it would be unresaonable not to.) Making custom syscalls
>isn't, which is why I didn't mention that for AFS - but if you have
>custom syscalls, I see no reason why they can't affect whichever
>process you want them to.
Again, it boils down to real world issues ... I'm saying that rather
than hack on AFS for a NetBSD-specific hack, I'd rather spend my time
writing PAM modules, since I have a chance of that work being reusable.
Yes, PAM doesn't exist for NetBSD, yes ... I'm saying what I would do
if it _does_. And yes, I don't _need_ PAM ... I can install a custom
login program (which I what I do now), or integrate it into the provided
login program. But, again ... time isn't infinite. The more time I can
spend on a reusable solution, the better.