Messages in this thread |  | | Date | Fri, 9 May 2003 16:30:32 -0400 (EDT) | From | Derrick J Brashear <> | Subject | Re: 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
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/
|  |