Solaris ssh pam_krb

Nicolas Williams Nicolas.Williams at
Fri Mar 31 15:39:14 EST 2006

On Fri, Mar 31, 2006 at 01:27:49PM -0500, Ken Hornstein wrote:
> >I have lots of uses for PAGs besides tracking krb5 tix.  I don't want a
> >PAG-like item per-such use.  I want a daemon (least priv and all that)
> >that tracks PAG<->{whatever} associations.
> I'm curious ... why do you want a userspace daemon to be involved?  I think
> you could simplify things by making a complete kernel-only implementation.

Flexibility, kernel memory usage.

First-class AFS-like PAGs would be a cheap facility requiring no special
caller privilege, and there's little scope for attacking the kernel -- a
tight for loop over setpag(2) won't hurt anyone, particularly if PAGs
are 64-bit numbers (at worst you may want to microsleep for a milisecond
per-setpag() call.  Even if we throw in empty-PAG notifications we still
have a small, constant size of memory consumption per-PAG, at most
per-process (fork() many processes, have each call setpag(2)).

First-class multi-application PAGs would not be so cheap in the kernel,
and there would have to be a finite number and registry of applications
to prevent resource consumption attacks.  Adding applications to the
registry would be a complication (you don't want to have to reboot for
that) requiring privilege.

I grant that altogether it's not *that* much more complicated than the
simple-kernel-PAG-with-multi-apps-support-in-user-land approach.  It
seems mostly a matter of moving complexity around...

> I know that gssd is userspace, but that's obviously because it would suck
> to cram the whole Kerberos and GSS libraries into the kernel.  If it's
> just "associate this processes tree with this cookie", then it would be
> simpler (I think) to make the whole thing kernel-only.

...and I tend to prefer having the complexity in user-land as that's
easier to debug and patch (rebooting vs. restarting a service).

> (I am personally not worried about the API; I'm sure whatever the API ends
> up being, it will be fine.  It's the implementation that concerns me).

Do you prefer a kernel-land implementation?


More information about the Kerberos mailing list