[OpenAFS-devel] [PATCH] new features for pam_afs

[Derrick J Brashear]

On Thu, 30 Aug 2001, Carsten Jacobi wrote:

> > > So that things like `ls -l` show the right thing for that user's files, even
> > > if he isn't allowed to log in there.
>
> There is one more reason to have the passwd entries. Actually the user can (!!)
> login, she just can not login locally (pam_afs.so will let her/him in before
> pam_pwdb.so or pam_unix reject her/him because of an unvalid passwd entry).
> But after authentication login still needs a home directory and a start
> shell, and this is not provided by pam_afs.so ... so we still need a local
> entry in /etc/passwd.

Sorry, I was wondering when you needed one when a user would not be
allowed to log in at all as opposed to not be allowed by one or the other
module not to log in, which I suppose I did not make clear.

> > Actually given that you have PAM adding a module to permit or deny login
> > on a per-user basis is very easy, there are already several modules which
> > permit use of such a database; I wrote such a module long ago, and should
> > have remembered to suggest such a solution.
>
> Do you have references for those suggestions? I am very interested and I know
> well that the "check_pw_entry" option is not a "clean" solution to implement
> a per-user distinction for PAM authentication. In my opinion, the PAM configu-
> ration should be 2-dimensional (one dimension for the service, and one more
> dimension for the users) so that the sys admin can define which user is
> authenticated by which PAM module for which service.

Mine is called pam_restrict and can be gotten from
ftp://ftp.dementia.org/pub/pam, but you probably don't want that one given
the external library needed (which you can get, and it then allows use of
AFS pts groups to manage who can and cannot log in)

The pam_listfile (I think) module included in linux-pam should give the
ability to use a simple flat file.

> The "check_pw_entry" was just the quickest solution I can think of making the
> per user authentication destinction we definitily require here.

I don'r dispute the need for it, just this implementation, and just this
implementation for broad distribution.

> On the other hand, it is not a good idea to include an option officially
> that will be obsolete when a better solution is out and end as legacy that
> still has to be supported because there are admins who started to use it
> and then rely on it.

Right.

> So, I am just looking forward to reading about the per user based PAM setup
> and if it is not needed at all I will remove the "check_pw_entry"
> option from the patch ...

Well, hopefully this is a start. If you need more I will dig further after
next OpenAFS release.

-D