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

[Derrick J Brashear]

On Fri, 9 May 2003, David Howells wrote:

>
> > > I'm wondering how attached OpenAFS is to this interface? Can OpenAFS be
> > > altered to use the following access points instead:
> >
> > Generally I think this interface will work.
>
> It would be nice, though, not to have to worry about differentiating between
> pioctls that take a path and those that don't inside of the core kernel.

I think it may be safe to not deal with them and assume some other
interface (sysctl or something appropriate) will be used.

> > >  (1) setpag(pag_t pag)
> >
> > If you don't specify a pag it should allocate you one, and for
> > non-priviledged users this should be the only allowed mode.
>
> Thinking about it, this shouldn't take an argument at all, and should just put
> its caller into a completely new PAG with a unique ID.

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" being the calling process? That can be done. I could just define that it
> is permissible for the PAG pointer to be NULL. This makes support for the init
> process easier, as I don't have to compile in a PAG for it.

Yes, I as the caller.

> > Currently it's possible to set a token when you have no pag, and these
> > become associated with the uid that set them. (The pag number is not the uid;
> > Instead any process without a pag but with a uid that has tokens associated
> > with it gets those tokens.) As long as the above don't bind tightly to a pag,
> > sure.
>
> So you'd have a list of tokens associated with the user too?

A uid could have tokens associated with it. They'd get used only for
PAGless processes running as that uid. Join a PAG and they stop being
visible to you (the caller)

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

> > As to pioctl, will it be able to handle things where path cannot be stat'd
> > in advance? For instance, the prefetching hint (VIOCPREFETCH), if you
> > could stat it, it wouldn't be a prefetch. Another concern there would be
> > dangling mount points (a mount point you still have to a volume that's
> > been deleted) when calling VIOC_AFS_DELETE_MT_PT or VIOC_AFS_STAT_MT_PT.
>
> The latter pair of pioctls you've mentioned both require the directory holding
> the mount point to be locally available as a kernel inode, and both of them
> require the path to that directory to be supplied as the path argument to
> pioctl rather than the path of the mountpoint, so I don't see that there'd be
> a problem there.
>
> 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.