[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

PAM_KRB5 and getpwnam() (was Re: pam_crypt module will change the world)



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
--





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []