Solaris ssh pam_krb

Nicolas Williams Nicolas.Williams at Sun.COM
Wed Mar 29 17:12:12 EST 2006


On Wed, Mar 29, 2006 at 03:53:33PM -0600, Douglas E. Engert wrote:
> 
> 
> Nicolas Williams wrote:
> 
> >On Wed, Mar 29, 2006 at 03:24:24PM -0600, Will Fiveash wrote:
> >
> >>On Wed, Mar 29, 2006 at 10:02:54AM -0600, Douglas E. Engert wrote:
> >>
> >>>If you really wanted to get this to work better, add a parameter
> >>>on to your pam_krb5 to support this, and have it set the KRB5CCNAME.
> >>
> >>Suggestion noted. 
> >
> >
> >Sure, but not enough -- the kernel-land kgssapi/krb5 code and gssd can't
> >use KRB5CCNAME to find a Secure NFS client process' ccache.
> >
> >We really need a concept like the AFS PAG...
> 
> Can you do anything like what DCE/DFS used to do? In response to a note
> on the OpenAFS mailing list commenting on the disjoint use of PAGS and
> ticket caches I pointed out DCE had a middle ground approach to keep the
> PAGs and ticket caches in sync.

The "last two supplementary groups add up to a PAG" thing?  That won't
go over well :)

We need a first-class PAG-like thing.

The audit session ID comes close to being that, but falls short (for
one, it's 32 bits, so too small, but also audit isn't on by default, and
the model is that you don't change a process' audit session ID ever once
set).  Process contracts also come close but fall short in that a
process can be in only one process contract and SMF use of process
contracts would conflict with AFS/DCE-style use of PAGs.  We could build
PAGs as extensions to process contracts, or as yet another process
grouping mechanism (which is how PAGs look in AFS).

Nico
-- 



More information about the Kerberos mailing list