Solaris ssh pam_krb

Ken Hornstein kenh at cmf.nrl.navy.mil
Fri Mar 31 17:38:30 EST 2006


>If you're using Kerberos V for authentication in remote administration
>protocols and have, say, 30,000 hosts to look after then your ccache
>would grow to:
>
>14KB x 30,000 = *huge* (~410MB)

Oh, come on ... this is a strawman argument.  You'd have to make some
serious changes to make this work with what we have today!  Even with a
disk file!

>Sorry, tickets don't belong in the kernel.  Even with pageable kernel
>memory, and proper accounting.

It seems like it would make sense to let the user/administrator make that
choice, instead of focusing on a hypothetical worst case.  Sure, it
might be really bad for a few sites ... so they have to use something
else.  But why deny the choice for other sites?

>Given the choice of complexity in the kernel vs similar complexity in
>user-land I tend to prefer the latter.

I can't think of any kernel-land application that can't live with an
upcall to user-space interface, like gssd does today.  The only thing
that concerns me is how is gssd going to access credentials in someone
else's PAG?  And if gssd can do it, then what prevents other user-land
applications that are not part of the user's PAG from doing the same
thing?  The one thing I really like about the current implementation of
AFS PAGs today is that root can't get at anyone else's AFS tokens
without diving into the kernel.

Now, I'd be happy with something that we could hypothetically call
"nfslog" that would talk to gssd or the kernel directly and run in the
user's PAG to get tickets.  Well, I guess "happy" wouldn't be the right
word ... I'd be _satisfied_ with it.

--Ken



More information about the Kerberos mailing list