Yes I think we agree, accept on the final comment on building kernels. That works for some, but not the masses that we need to sell on AFS.
"Todd M. Lewis" wrote: > > 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? > -- > +--------------------------------------------------------------+ > / [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl / > / A hangover is the wrath of grapes. / > +--------------------------------------------------------------+ > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
