[OpenAFS-devel] Re: [OpenAFS] 2.6 kernel support anytime soon?Workarounds?

[Todd M. Lewis]

Douglas E. Engert wrote:
> I think you are missing the point. I am not saying that the semantics of 
> a PAG is all wrong, I am saying that the implementation of overloading
> the group structure in the kernel is a problem for a number of reasons. 
> [...] 
> I was looking for an approach that would solve the first at least and 
> maybe the second with in some reasonable time frame like the next two months.
> I am trying to be practical about this.
> [...]
> What I was looking at was not having to get anything by the kernel developers
> at all! But rather use what is already available to a file system to associate
> a PAG with a process.  

I think we're agreeing about everything here, it's just that the 
short-term expediencies and long-term strategy may take two different 
paths.  Something that works now, or very soon, would of course be welcome.

>>Yeah, I'm supposed to provide the patch with such a suggestion. Sorry.
>>But I'm firmly convinced that PAGs are not the bag-on-the-side of the
>>existing groups facility, but rather unix groups were the good enough
>>for the times bag-on-the-side implementation from back before we
>>understood what credentials really were or what they could do for us.
> 
> One way to look at the uids and gids are that they are "the" credentials
> for use to access the local file systems. They are very simple, but are under
> control of the local kernel, and trusted by the local file system as it is
> also run from the kernel. But they are still only local. More traditional
> credentials have their trust rooted in some outside authority, and thus
> are much more complicated. But the traditional use of uid and gid is so ingrained
> in Unix that it is hard to think of using these in any other way. 

True, and I don't want to break how uid and gid are used. I just want to 
extent in a useful way the mechanism that propogates them from process 
to process. You're right, it is hard to think about, but... suppose for 
a minute that we could generalize the credentials thing so that local 
user/groups were handled the same way that AFS, NFSv4, IPsec, etc are. 
(Granted, the uid/gid implementation would be drop dead trivial.) Of 
course these filesystems would insist on using there own credential 
mechanisms, but if we get the abstractions right, an admin could 
delegate authority to _any_ credential mechanism. For example, you could 
set up a local storage, say under riserfs or ext2/3, and delegate 
credential authority to use AFS's, er, stuff (I'm waving my hands wildly 
here, makes it hard to type). So I could have some local file space that 
follows AFS's permission models. It's not an AFS server, but local 
processes don't need to care. Or, say I put up some weird credential 
mechanism perhaps based on some neat new technology but with no 
corresponding filesystem. With the abstraction done right, I could set 
up some local or perhaps shared file space and delegate credential 
authority to it. Or something that could handle directory or file level 
ACLs. Or a bunch of things nobody's thought of yet, and never will until 
a mechanism is available to make it possile. But don't let's forever 
limit local credentials to 16 static groups and 9+ bits/file.

Granted, I'm not addressing the immediate, legitimate, OpenAFS vs. 2.6 
issues, nor anything that's ever going to make it into 2.6. But 2.7 
might be different. And it needn't break the traditional use of uid and 
gid in situations where that's an appropriate solution. But expanding 
the scope of local group inheritance to allow additional credential 
mechanisms could have benefits besides that of (btw) allowing AFS to work.

> So in the long run a kernel does need to be able to handle network credentials 
> be it for AFS, NFSv4, IPsec or even the local file system.  I don't deal enought
> with the Linux Kernel developers to know if they have gotten this yet.     

Like I said before, I don't think you can sell this idea to them unless 
they see some local benefit, or at least make a strong case that it's a 
break even proposition for stand-alone machines. It could allow 
networked Linux machines to do what nothing else (that I know of) does. 
(Except it doesn't pass the "Show me the code" argument. Yet.)

Aside from the pie in the sky, I'd like a 2.6 mechanism for OpenAFS too, 
but I don't (much) mind building kernels to get it.

>>p.s.: Yes, I'm the guy that suggested eliminating tabs from the OpenAFS
>>sources. Radical ideas for radical times, no?
-- 
    +--------------------------------------------------------------+
   / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
  /              A hangover is the wrath of grapes.              /
+--------------------------------------------------------------+