On Wed, 18 Apr 2001, Nicolas Williams wrote: > > Hey, I'm game if you are. :) I do in fact think this is a good idea; I can't > > think of any reason that pam_krb5 should need to verify that the user exists > > locally in order to do authentication. > Right. BUT, how should pam_krb5:pam_sm_setcred() handle ccache creation > if the PAM_USER has no Unix account? I suppose it could generate a > random ccache file name or shared memory name and make it be owned by > the euid in effect at the time it gets called. Choose a secure default value for the cache permissions, yes. If there's no associated local user, give the cache file mode 0600 and leave it owned by the euid of the application. Suppose I have a web application that does Kerberos+AFS authentication using PAM. The webserver is never going to have sufficient permissions to chown the file anyway, so having a local user associated with the Kerberos principal isn't terribly important; but having pam_sm_setcred() correctly create & destroy the ccache makes all the difference if the web app tries to access AFS. > I think we might want to make such behaviour optional. Too many options :) Is there ever a case where doing setcred() for a non-local user and just not chowning the cache would be detrimental to security? > > Even if we remove all direct calls to getpwnam() from the authentication side > > of the module, there's still a getpwnam() call being done for us in the > > account management stuff that we can't avoid: how do you check the .k5login > > file for a user whose homedir you can't find? But maybe that's ok. > Well, krb5_kuserok() won't work if there is no Unix account, BUT, if > krb5_aname_to_localname() maps a given principal name to an account name > that matches PAM_USER (this is *before* PAM_KRB5 reset's PAM_USER) then > we can say the user is authorized. krb5_kuserok() does the same check > too, but only if ~/.k5login doesn't exist. > Hmmm. Hmm, indeed. Steve Langasek postmodern programmer
