Solaris ssh pam_krb

Jeffrey Hutzelman jhutz at cmu.edu
Thu Mar 30 18:58:39 EST 2006



On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams 
<Nicolas.Williams at Sun.COM> wrote:

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

Actually, that's what AFS does, except it's the _first_ two groups; we 
shift the others out of the way as needed.  It works reasonably well, 
provided you restrict your GID space to not otherwise use the groups AFS 
uses, and restrict your UID space to not use UID's that would conflict with 
PAG ID's (this wasn't a problem in the days of 16-bit UID's, but it is 
today).


> We need a first-class PAG-like thing.

Please!  Be the first OS vendor on your block to provide them!


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

Right; AFS PAG's are just another kind of process group.  They happen to 
have exactly the same inheritance semantics as supplemental groups, except 
that setgroups() doesn't touch them, and any process can ask for a new one. 
(In addition, AFS let's you get a new PAG and ask for your parent to be 
moved into it with you; this lets 'newpag' be a program users can call from 
the shell.  But this behavior is considered an evil aberration that we wish 
would go away).




Anyway, what Doug is talking about is essentially keeping credentials in a 
file whose name can be derived from the PAG ID.  But there are various 
potential problems with this, among them the fact that users may not _want_ 
their credentials to be used implicitly for file accesses.

-- Jeff



More information about the Kerberos mailing list