Re: Adding an "acceptable" interface to the Linux kernel for AFS

[David Howells <dhowells@warthog.cambridge.redhat.com>]

Hi Derrick,

> There are valid reasons to allow a PAG to be specified, but only with
> priviledge. e.g. user mode protocol translator (afs to nfs)

I suppose I can do that... I can add a hook to the security framework or add a
an extra capability to allow a finer degree of control.

Perhaps:

	newpag()	<--- new PAG
	setpag(0)	<--- no PAG
	setpag(>0)	<--- join PAG if permitted

> > I suppose I could give both the PAG and the user lists, and search the PAG
> > first, then the user, but what detemines the user? The PAG, the opener of a
> > file or the current process?
> 
> The uid of the current process. Again, if you're in a PAG you don't get
> uid tokens. You could create 2 PAG number spaces, 1 using uid
> and one sequential alloc, but then you need more management I guess (or to
> assume kernel code will be able to provide hooks for accepting tokens
> regardless of PAG and just let people who care deal in their code)

Getting the per-user PAG data from the current process becomes a little
trickier when worker kernel threads become involved:-/

Maybe each user_struct should _also_ have a normal PAG associated with
it. Asking for "no PAG" joins the calling process into its owner user's
PAG. Then you only need one number space...

However, doing this would affect authentication tokens for every FS that
stored them in this way, not just AFS (Samba for instance).

> > I don't have documentation on VIOCPREFETCH, but if it's anything like the
> > other two, then it shouldn't be a problem either.
> 
> Takes a path to attempt to prefetch as a text string.

I take it that "prefetch" means try and fetch the entire file into the cache?

David