[OpenAFS] OpenAFS on Linux 2.5.x

[jon+openafs@silicide.dk]

On Wed, Apr 16, 2003 at 08:48:08AM -0400, Derrick J Brashear wrote:

[cut]

> I guess that would be
> -essentially precluded us from continuing to provide the functionality we
> do now (because sys_call_table has become private, we must not hook the
> setgroups/getgroups system calls for doing PAG management. that's not
> really unreasonable. however, some bit of per-process state needs to exist
> and be propagated across fork. the only obvious other thing in the task
> structure was being eaten by people who hated that the other patch which
> had been incorporated at the time touched so much of the code. basically
> that code was intended to allow a lot of hooks into the kernel for
> security auditing, and apparently a large number of people felt hooks were
> unclean. the hook we would have used would have allowed us to create an
> object and chain it into a pointer off a task struct, then cause it to be
> copied on a fork. the big deal here is 2.5 was supposed to be
> feature-frozen essentially immediately after this, so basically the net
> effect from where i'm sitting is "you can't have what you need to enable
> you to keep working".

Then one would have to find other ways to get it working. 
What work have the ARLA people been doing ? Do they have
a working client? perhaps one that can be modified ?

 
> and
> -i don't think they treat me, particularly, as a second-class citizen, but
> instead, that afs gets that treatment. i think i elaborated on that a bit
> already in a previous message. if not, and if no one else has, and if you
> think it matters, i can explain that.

No, it doesnt matter that much.


> basically, what you chalk up to potential arrogance, or perhaps to
> arrogance regardless, i can explain as this:
> -many parts of afs use the afs system call. currently there is no way for
> these to work in linux 2.5 and beyond. by and large these can be
> rewritten.

Good, at least some functionality is needed.


> -in order for PAGs to continue to work, we need some way to track process
> creation and parenting. without that, it's not worth my time, personally,
> to work on the client, because i need PAGs. i can't speak for anyone else,
> because i have no employees who i get to speak for;-)

why not store all the different PAG's the same place in the kernel,
and then just look up there everytime a process needs a file. True
it does take time, but at least it might work, and how many concurrent
different users do you have anyway, so how big will the list/tree/array
be? It could even be made so it is only the first time a process asks
for a file it is checked if it can do that.

So you have this process, and see if it has access. If you dont know
you see if the parent has access, and then if that parent has access
and keep doing that untill you find either a yes or a no, and return
that answer. (usualy the parent will have access, and so will the
child, and then you remember the pid of the child. If you keep some
sort of balanced tree, it shouldnt take that long to look it up.
(yeah yeah, i realise that i dont know anything beyond these emails
some understanding of kernels and the linux kernel, + 
http://grand.central.org/twiki/bin/view/AFSLore/ProcessAuthenticationGroup
but still i'm sure that a workarround can be made. It might not be
pretty, but then we have something to fix in the next stable kernel
release.)


JonB