Douglas E Engert <[EMAIL PROTECTED]> writes: > 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_kuserok was called (There might be some other dot files that > could also be accessed early.) Getting this ticket early does not > changed the security model, as the checking of the .k5login is to allow > access to the local machine, not the AFS file system. The forwarded > ticket and token could be discarded if the krb5_kuserok fails.
The client is, understandably, not going to forward the ticket until after the authentication step is complete, so what this basically means is authenticating the user, accepting the forwarded ticket, and then reauthenticating the user. I guess it would be possible to do this, but ew. I'm guessing ew would be the OpenSSH upstream reaction too. And this doesn't help with the PAM situation, where you don't get an AFS token until after pam_setcred is called, which is after pam_authenticate, and some programs only call pam_authenticate and never call the other PAM functions. This is probably wrong of them, but still, it shouldn't introduce a security hole. I suppose you could fall back on the standard PAM cheat of doing everything in pam_authenticate and making everything else a no-op, but that too breaks in other situations where people call pam_authenticate in a different context than pam_setcred (OpenSSH is again at fault). I don't see a good solution to this, unfortunately. I wish that AFS supported the directory lookup semantics supported in Unix with execute but no read, but I can see why that would be rather hard to do. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
