On Wed, Apr 18, 2001 at 06:12:33PM -0500, Steve Langasek wrote: > On Wed, 18 Apr 2001, Nicolas Williams wrote: > > > > I would certainly call this a bug (except in modules like, say, pam_unix). > > > Not something that we can't fix without replacing getpwnam(). :) > > > Ok. I guess that means I should rip out all references to getpwnam() in > > PAM_KRB5... Should be easy enough :) > > 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. I think we might want to make such behaviour optional. > 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. > Steve Langasek > postmodern programmer > Nico --
