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

[Douglas E. Engert]

Jeffrey Hutzelman wrote:
> 
> On Wednesday, May 12, 2004 14:50:56 -0500 "Douglas E. Engert"
> <deengert@anl.gov> wrote:
> 
> >
> >
> > Garrett Wollman wrote:
> >>
> >> <<On Wed, 12 May 2004 14:13:53 -0500, "Douglas E. Engert"
> >> <deengert@anl.gov> said:
> >>
> >> >  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.
> >>
> >> Not just Linux -- any reasonably modern SMP operating system is going
> >> to have similar problems (or at least, the alternative is an
> >> even-worse tangle of #ifdef spaghetti to manage the locking
> >> requirements for every operating system's credential implementation).
> >>
> >> Thankfully, most systems passing the "reasonably modern" test have
> >> already had to implement some sort of extended credential mechanism,
> >> where MAC labels or something else.  Some of these mechanisms may not
> >> be sufficiently flexible to do what AFS needs, or may not be available
> >> in the standard version of the OS.  (In FreeBSD this is no problem;
> >> the MAC functionality comes standard and includes all of the hooks
> >> that AFS needs; I just have to get down to writing the code.)
> >
> >
> > I agree, now what about Linux 2.6?
> >
> > I gave a outline earlier today about shadowing the task_struct and
> > group_info, but have not got any comments back on if this would work
> > or not.
> 
> I've commented already.  I'm not interested in keeping a pointer to a data
> structure that doesn't know I have a pointer to it.  That's inviting
> trouble, like dereferencing a pointer that no longer points to what you
> think it does, and stomping all over someone else's memory or just losing
> to an invalid memory access exception.  Data structures get freed.  Memory
> gets reused.  This is not clean or safe.
>

You commented on the first, but not the second. In the second I thought I addressed
the issue of a task_struct getting reallocated by using the start_time,
and the group_info usage count would be incremented so it would not be freed
without AFS knowing about it.  
 
> I thought I also explained why this isn't good enough -- it's trivial to
> construct a situation in which a process loses its PAG.  The steps you have
> to go through do sound a bit contrived, but only until you realize how
> trivially they are satisfied in the login process before the user even gets
> control.
> 
> As I mentioned before, I wrote code many months ago to track PAGs without
> trapping setgroups.  I used the supplementary groups list, but also a
> private process->PAG map, a magic file descriptor, and an algorithm that
> involved walking up the chain from one parent to the next looking for a
> PAG.  Let me say it again...  I DID THIS ALREADY.  I HAVE RUNNING CODE.
> What I discovered is that it works reasonably well, but not perfectly.   If
> folks want to look at the code, I might be able to dig it up.

If you have it working, I think it would be great idea to dig it up. 

As I keep saying, the linux 2.6 problems need to be addressed, even if
it requires something like this, rather then something simplier that 
the Linux kernel people are not willing to implement.  

> 
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA

-- 

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