Re: [OpenAFS-devel] Re: MEMORY credential cache interop between Heimdaland MIT?

[Howard Chu <hyc@highlandsun.com>]

Henry B. Hotz wrote:
> On Aug 30, 2007, at 12:39 AM, u+openafsdev-sr55@chalmers.se wrote:
>> PAGs are supposed to be handy, but they contradict the basic *nix  
>> design,
>> which is built around uid as the main credential.
>> So they are controversial by nature.
> 
> The basic *nix design was oriented toward single multiuser machines.   
> The uid is completely useless as a credential for accessing network  
> resources.  Perhaps PAGs contradict the design, but that's because  
> the design is not applicable.  Obviously that has user-visible  
> effects, but I see no issue there except that the user needs to learn  
> the difference.  (Or are you proposing that Unix should be updated to  
> use a network-verifiable identity in place of the uid?)

I think this is slightly overstated. uids worked just fine for networks managed 
by a single administration domain. Where they fall down is when you cross 
administrative boundaries, and that's where domains/realms/whatever enter the 
picture.

> I agree that the scoping mis-match between uid's and PAGs is a  
> security issue.  Likewise the scoping mismatch between PAG's and  
> <pick one> Kerberos credential cache's is an issue.  Please propose  
> what you think the model should be, but if you say Unix uid's then I  
> strenuously disagree.  I happen to think the process inheritance tree  
> is a good scope to use, as I described in my post.

With other concerns understood, yeah, I think the process inheritance tree is 
an OK model. It may very well warrant a kernel-supported implementation as 
well, since userland (descriptor inheritance) can be derailed so easily. But if 
you're going to the trouble of writing kernel code to implement it, do it 
right. E.g., walking up the process tree when someone issues an ioctl on a 
device is not going to give reliable answers. The ccache handles have to live 
in the process' user struct so they are implicitly copied at fork() time. (At 
least the setgroup() hacks got this right.)

> How easy/hard that is to break is an implementation issue that I  
> would discuss in terms of how well the PAG model was implemented.  As  
> others have noted there will always be gaps and holes.  In fact I  
> would go one farther and say that Goedel's Theorem absolutely  
> guarantees there will be gaps and holes, regardless of what model you  
> use.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/