I have played a little with the afs-pam module lately. At our site we are
looking for a
sensible domain environment and an AFS cell may be an option.
What I actually aimed was to provide users a file server on which they can
directly
log on to the Kerberos realm of our AFS cell. Nevertheless, a root log on
to the same
machine is still to be kept local.
So from my point of view it makes sense to set a Nill-Password for all
users with
AFS access in the local /etc/shadow file. Thus, if a user logs in the
pam_unix module
will grant access without prompting for a password, but pam_afs should send
its password
prompt. The pam file (Red-Hat) would look like this:
/etc/pam.d/login
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_afs.so try_first_pass
This setup will work fine for all users with AFS cell access, but won't
grant access for
user "root" ... it would, but "root" does not have an AFS password of
course.
That is the reason, why I included the option "trust_root". The option
should tell pam_afs,
that the access shall be granted as soon as the user "root" is concerned.
The new file looks like this:
/etc/pam.d/login
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_afs.so try_first_pass trust_root
So far the setup works fine, but there was still one shortcoming. When a
user is already logged in,
but she wants to change with "su" to root it is much more difficult to make
the distinction between
"remote user wants to log in as AFS user" or "remote user wants to log in
as root". Maybe I got
it wrong, but for me it seemed as if login is running as "root" (uid=0)
when it is calling the pam module
for authentication whereas "su" is running as the current user id (uid!=0)
when it is calling pam.
The pam_afs module on the other hand relies on the current user id (uid=0)
of the authenticator
to find out the difference between root logins and non root logins. So, I
added even one more option
called "catch_su" that activates one more check (there was no choice but
using strncmp to check
the typed in username to change to). The option also "redisables" the
variable use_first_pass in
afs_setcred.c because in contrast to the login behaviour the super user
shall be prompted for
an AFS password when he wants to change from root to user state (in this
case su runs as uid=0
which is misinterpreted by the afs module as "change to root" instead of
"change from root").
The pam file for su will then look like this:
/etc/pam.d/su
auth required /lib/security/pam_stack.so service=system-auth
auth required /lib/security/pam_afs.so try_first_pass trust_root catch_su
I tried some logins back and forth and so far the setup seems to do what is
supposed to. Anyway,
I would like to have the attached patch included into the pam modules. Or
does somebody have
any doubts? Maybe I left something out (for example a leak) ...
Carsten Jacobi
(See attached file: openafs-1.0.2-pam_trustroot.patch)
openafs-1.0.2-pam_trustroot.patch
