[OpenAFS-devel] kuserok() checking UID ownership on afs

Douglas E. Engert deengert at anl.gov
Wed Feb 2 15:00:54 EST 2005

Harald Barth wrote:

>>This assumes that there is already an AFS token.
> I assumed a forwarded ticket.
>>The .k5login (and other dot files) have always been in a chicken and
>>egg situation.
> Yes. The order is critical and tricky.

Its really more then Kerberos/AFS problem. Its a distributed file system
access problem vs the Unix assumption of root can always access the user's
home directory.

To access the distributed file system needs some credentials, either
from the user or maybe the machine has an AFS token, and the machine
is listed in the ACL of the potential home directory.

> I think there should be an order to
> 1. Aquire krbtgt (forwarded or with passwd) to memory
> 2. Setup AFS stuff (afs service ticket, token, pag) if possible
> 3. Evaluvate .k5login
> 4. Decide if user is OK
> 5. Give ticket to user
> 6. Login user into pag from above

Yes, but more generically:

  1. Authenticate network user without looking at home directory.

  2. Use any acquired credentials or machine credentials to access
     the implied home directory (i.e.authenticate and authorize the
     user to use the distributed file system.) PAGs and tokens.

  3. Continue with authorization checks like .hushlogin,
     .k5login, ssh keys, etc.

  4. If user authorized on local machine, then pass the PAG and
     credentials to user's process.

This needs to fit with PAM and any daemon that calls PAM or does its
own authentication/authorization. pam_sm_authenticate does authentication,
pam_sm_open_session does the kuserok.

> This does only work if the user either is at the console with password
> or forwards tickets. 

Why not? It means the console login or PAM needs to do the above steps too.

> But if you have AFS on the remote system, you
> probably want to forward tickets if your $HOME is in AFS. 

Yes, like openssh with gssapi and delegated credentials then pam_sm_session
doing the kuserok.

> I don't know how difficult it is to bend the kerberos code into doing
> the above. Probably not my league. You know the kerberos code much
> better than I do.

Its not the Kerberos code that needs bending its the login applications
need to get credentials to access the potential home directory
before trying to access any files in the home directory.

BUT - There might be some considerations for a DOS.  For example, a valid
Kerberos user is not authorized to use some server. The user could get that
server to do a lot of extra work getting AFS tokens just to find out
that the user is not authorized based on the .k5login. But then these
things would get logged, so the user would get caught soon enough.

> Harald.


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

More information about the krbdev mailing list