On Monday, March 13, 2006 07:57:17 PM -0500 Chaskiel M Grundman
<[EMAIL PROTECTED]> wrote:
--On Monday, March 13, 2006 13:45:04 -0500 Jack Neely
<[EMAIL PROTECTED]> wrote:
Its a
much better solution and will lead toward much happiness in the end.
It's a less-hacky solution. I would not call it "better". (At least I
don't think it's worse anymore. until about 5 minutes ago I thought there
was a problem with the access control model because "any" process could
join any session keyring. That turns out to be incorrect)
I use several third party tools with OpenAFS that this would break. I'm
willing to work with maintainers and fix them to use the kernel
keyrings.
The only thing that needs to change is the setpag operation.
instead of
syscall(AFS_SYSCALL, AFSCALL_SETPAG);
or more likely, after it fails.
you would need to do the following keyring operations:
keyring = keyctl_join_session_keyring(NULL);
/* This setperm operations revokes all the "owner" rights
If that were not done, any process could join any pag belonging to the
same uid */
keyctl_setperm(keyring, KEY_POS_ALL);
lastly, you'd need to call a new afs-specific operation to create the afs
pag key in the session keyring. it would probably be a new pioctl. It is
conceivable that the final design of keyring based pags would skip this
step and just use the serial number of the session keyring as the pag id.
I haven't thought through all the ramifications of that yet.
Of course, one of the pieces we're waiting for is for the right interfaces
to be exported by the kernel so that AFSCALL_SETPAG can do these things for
you.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
