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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:32 EST