Solaris ssh pam_krb

[Nicolas Williams]

On Fri, Mar 31, 2006 at 05:38:30PM -0500, Ken Hornstein wrote:
> >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!

I know, but *I* needed this once.

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

GSSD, today, is a privileged application.  In the future we may have
per-user or per-PAG GSSD instances, with the primary GSSD serving only
as a registration service for the former.

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

I'll take your being satisfied :)

Nico
--