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

[Douglas E. Engert]

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?
> --
>     +--------------------------------------------------------------+
>    / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
>   /              A hangover is the wrath of grapes.              /
> +--------------------------------------------------------------+
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444