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

[Douglas E. Engert]

"Todd M. Lewis" wrote:
> 
> Douglas E. Engert wrote:
> >
> > Derrick J Brashear wrote:
> >
> >>Ok, that's great. So, what should we do about it?
> 
> Reimplement groups. No, really.
> 
> > Is there another way to look at the PAG problem rather then having to
> > use the groups? Using the groups to store a PAG was a convenience for
> > the AFS Kernel routines to find credentials associated with a process,
> > but does not appear to be a requirement.
> 
> There is no other way. The reason passing a PAG as a special pair of
> groups gives us the right semantics across a dozen platforms is because
> PAGs do what "regular" groups were supposed to do.

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. 
 
 o  The need to trap the setgroups syscall is a problem that needs to be 
   be addressed as newer kernels (Linux 2.6) will not allow this.
 
 o As many have pointed out on this list on the last two days, they did 
   not realize that the way the PAG is stored in the groups might give 
   some processes access to data they should not have, as the PAG my match 
   an existing group. 

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.  

Even adding an extra uint32 to the group_info for a PAG number would greatly
simplify things, as it would not overload the groups, yet would get
propogated with the groups.  

> 
> The sad part is, groups just don't cut it anymore. The /etc/groups is a
> poor substitute for ptserver, and -rwxrwxrwx is a poor substitute for
> file level ACLs. The process supplemental groups list should become a
> generic credential handle cache with no specific groups in it. Instead,
> those groups should be stored in a "local" credential structure just
> like AFS tokens, the coming NFS credentials, and as yet unthought of
> credentials, respectively, should be stored.
> 

I totally agree. But we have a problem today with Linux 2.6, and all the
email since it came out over this makes it sounds like the kernel 
developers will not budge on the syscall trap issue. So we need another approach.


> Reimplementing local groups as just one of many credentials mechanisms
> would be a big shift, but the supplemental groups list has exactly the
> right semantics; recreating those semantics via another mechanism is
> just wrong -- aesthetically wrong in the sense that it'll never make it
> past the kernel developers. 

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.  

> The major changes of late that have made the
> cut do just the opposite; they generalize similar redundant mechanisms.
> It would have to be really well done so that current group handling
> doesn't take a significant hit. The kernel gatekeepers aren't going to
> take such a change unless there are obvious payoffs. Perhaps with NFS
> also needing such a facility, and NFS being more palatable to the kernel
> guys, they might at least give it a look.

I agree with this, and the NFSv4 and AFS need to work together, (and are
as far as I can tell.) 

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

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.     

> 
> Cheers,
> --
>     +--------------------------------------------------------------+
>    / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
>   /        Marriage is the mourning after the knot before.       /
> +--------------------------------------------------------------+
> p.s.: Yes, I'm the guy that suggested eliminating tabs from the OpenAFS
> sources. Radical ideas for radical times, no?
> 
> _______________________________________________
> 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