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

[Derrick J Brashear]

On Fri, 9 May 2003, David Howells wrote:

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

Sure.

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

As long as the PAG number itself is tied to and not directly the uid, that
should work.

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

If each FS has its own tokens, I assume there's no problem if you don't
allow setting of any for those that don't support non-PAG tokens?

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

Yes.