[OpenAFS-devel] Re: new features for pam_afs

Todd M. Lewis Todd_Lewis@unc.edu
Thu, 30 Aug 2001 10:00:44 -0400


Carsten Jacobi wrote:
> 
> On Wed, Aug 29, 2001 at 03:39:23PM -0400, Derrick J Brashear wrote:
> 
> 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.
> 
> > 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.
...
> 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

You might be interested in the ideas behind my "propup" PAM module. It's
an admittedly quick and dirty solution to a problem I had with the
machine in our conference room. I didn't want to have to deal with
adding passwd entries for our staff -- or whomever else might be trying
to use the machine -- so I wrote propup. As the first PAM module called
for local logins, it checks the passwd file for the user who's trying to
login. If he isn't there, it checks a flat file in AFS that we keep of
our current users and certain associated properties. From that it can
figure out if the user should be allowed to login. If so, it then adds a
passwd entry for him with his home directory in AFS and a shell that
will probably work. In any case it returns success, so the "real"
authentication modules can allow or deny him access.

You could modify propup to do other passwd file fix-ups to suit your
needs, and beef it up to fit your security comfort level. It's at
http://www.unc.edu/~utoddl/pam_linux_afs/ (which also has Tobias
Schaefer's pam_linux_afs module with a patch to handle some reuid issues
I ran into). The file you might want is propup.tgz.
-- 
   +------------------------------------------------------------+
  / Todd_Lewis@unc.edu              http://www.unc.edu/~utoddl /
 /(919) 962-5273               Lord, give me patience... Now! /
+------------------------------------------------------------+