[OpenAFS-devel] keyring/pag support for linux

[David Howells]

chas williams - CONTRACTOR <chas@cmf.nrl.navy.mil> wrote:

> >Whilst I could do that, I'm not sure it'd help you as you'd need to use the
> >RCU interface to access keyrings directly.
> 
> i am not sure about that.  i dont need direct access to the keyrings
> just access to the keyring key_type so that i can create a keyring
> (this doesnt involve rcu).  while the keyring key_type does have 
> functions that involve rcu, they do not get 'included' in my binary.
> my only need for rcu comes when i need to modify the keyring pointers.

I see.  I suspect what you really want is keyring_alloc(), as you say:

> keyring_alloc() is all i need really to make keyrings.  then i dont
> need to see the keyring key_type (and no one should need to see it really).

Though you still need to do RCU to change the session keyring pointer...  Note
that:

	+        /* install the keyring */
	+        spin_lock_irq(&current->sighand->siglock);
	+        old = current->signal->session_keyring;
	+        current->signal->session_keyring = keyring;
	+        spin_unlock_irq(&current->sighand->siglock);

is _not_ correct.  The rcu_assign_pointer() you've removed is quite important
if you want your code to work on, say, PPC64 or Alpha - especially Alpha.

> >> or join_session_keyring() exported.
> >
> >That should be possible.
> 
> that would be be fine as well.  either is a solution.  i imagine that
> others might wish to create/delete keyrings from inside the kernel.
> there is no mechanism for that now.

The way you've done it in your latest patch is not a viable solution because
you have to do RCU to set the session pointer.

> >	static inline _syscall2(long, keyctl, int, option, void*, arg2)
> >	long serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING, NULL);
> >
> >Which isn't very nice, but which ought to work.
> 
> this is a userspace thing which i cannot use a completely compatible interface
> to existing users of the afs syscall.

No - it's calling a system call in kernel context.  It's possible, though the
clone syscall is usually the subject (kernel threads).

> so export install_session_keyring()

join_session_keyring() is better, I think.

Hmmm...  When setting up a new PAG, should the other contents of the existing
session keyring be copied across, I wonder...

> (and possibly some other functions like install_thread_keyring(),
> install_process_keyring()) so that users dont need to figure out how to
> safely duplicate the code in these functions.

Users shouldn't really be using these.  The intention was that request_key()
is the only interface that should be necessary.  I envisioned things like
keyring replacement being driven from PAM.

> >Another alternative might be to try putting the PAG stuff in the main kernel,
> >and add a keyctl function to set or get a pag.
> 
> unfortunately we need to make the existing afs pioctl/syscall interface
> work.  this is also a joke right?

No.  Just a suggestion.  It still may be feasible that it be placed in the
main kernel, with a way for it to be driven from a module also.

> >The main thing I'm not sure about how to do is to change the PAG to which a
> >process's parent subscribes.  It is possible, but the locking is interesting.
> 
> i am not completely certain, but i believe afs needed this feature 
> because the pags were inserted in the group list and the group list
> wasnt a single shared object.  the session keyring seems to solve this
> problem.

Okay.  I was looking at the change_parent argument to setpag().

David