[lkml]   [2003]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Adding an "acceptable" interface to the Linux kernel for AFS
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


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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.050 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site