[OpenAFS] home on afs woes

Douglas E. Engert deengert@anl.gov
Wed, 04 Jan 2006 13:43:58 -0600

Russ Allbery wrote:

> Juha J=E4ykk=E4 <juolja@utu.fi> writes:
>>In my opinion, the problem is pam_krb5.so, which checks the .k5login
>>file in pam_sm_authenticate(). Its own documentation says it only check=
>>.k5login in pam_sm_acct_mgmt(), but this is incorrect. I am not sure
>>this is a bug, though, and therefore haven't reported it. I just though=
>>there must be people around who have these three working together and
>>they must have a solution which is more general than depending on a
>>single pam module. Comments?
> .klogin and .k5login files have always had to be world-readable.  Consi=
> the case with ssh and forwarded credentials.  You have to authenticate =
> user before you can accept tickets for them, and in order to authentica=
> the user you have to be able to check the .k5login file.=20

I have always argued that there was some room for improvment in this area=
The .k5login should not have to be world readable. Let me explain my argu=

The sshd could accept a forwarded ticket for the sole purpose of using it=
 to get
an AFS token so the sshd could access the .k5login file before the krb5_k=
was called (There might be some other dot files that could also be access=
ed early.)
Getting this ticket early does not changed the security model, as the che=
cking of
the .k5login is to allow access to the local machine, not the AFS file sy=
The forwarded ticket and token could be discarded if the krb5_kuserok fai=

This would require some changes to do this, and I don't know of any site
that has done this. Its too ingrained in Unix that root has access to the
home directory during login.

>  Not checking the
> .k5login file at the time of authentication is a bug; you may authentic=
> a user who shouldn't be allowed to log in, and there are indeed program=
> (xlockmore, for instance) that only call pam_authenticate.
> The solution is to create a world-, or at least local-network-, readabl=
> directory in every user's home directory, grant l access to the top lev=
> of their home directory, move .k5login to the readable directory, and
> symlink it.  So far as I know, every site that uses AFS with Kerberos h=
> had to deal with this; Stanford has been doing this for all users for o=
> a decade.  The l ACLs on the top level of the home directory are rather
> unfortunate, but the other ways to work around this are much more compl=

We do this too.

Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.




  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444