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

[Carsten Jacobi]

On Wed, Aug 29, 2001 at 03:39:23PM -0400, Derrick J Brashear wrote:

> On Wed, 29 Aug 2001, David Thompson wrote:
> 
> > >non-password in the field like "X"? If the intent is to not allow login at
> > >all for accounts with a field "X" why put them in the passwd file at all?
> > 
> > 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.

> > I have problems with overloading the passwd field of /etc/passwd.  The 
> > non-portability issue here is very significant.  There are many authentication 
> > mechanisms that this could break.  If you want to choose an authentication 
> > mechanism on a per-user basis, the place to make the choice is in an auxiliary 
> > database (maybe just a flat file), not in /etc/passwd (or /etc/shadow).
> 
> 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.
The "check_pw_entry" was just the quickest solution I can think of making the
per user authentication destinction we definitily require here.
And since pam_afs will only success with users who have a "USE AFS" in their
passwd field, we are still able to push in pam_smb to look for "USE SMB" in
the passwd field so that we could also give users from a WINDOWS-NT domain
access to our servers and have them authenticated by the appropriate entity.
Those were my motivations for the "check_pw_entry" option. Also I would be
glad to have a better solution that does not break any other authentication
mechanisms defining a clear setup that can easily configured by the system
administrator. And as long as we don't have that solution ... I mean it is
just an option, if it breaks your setup you simply won't use it.
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.
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 ...

Carsten Jacobi