On Wed, 2013-11-20 at 21:21 +0000, Adamson, Andy wrote: > > Why do you need to abuse the keyring interface to implement a syscall ? > > Do you think this job requires a system call? > > I felt the keyring interface gives us what we want: a way to pass some > information and trigger a behavior. The gss-ctx key caches the > relationship between the principals Kerberos credentials and the > associated RPC layer gss_cred (which in turn has the gss_context). > When a gss-ctx key exists, the principal associated with the UID has > kerberos credentials (located in the Kerberos ccache stored in the > key) that are used for NFS, and the key serial is stored in the > gss_cred. > > From kernel documentation: Documentation/security/keys.txt > > "This service allows cryptographic keys, authentication tokens, cross-domain > user mappings, and similar to be cached in the kernel for the use of > filesystems and other kernel services." > > I think the gss-ctx key fits into the above description (under > "similar"), so I don't think of this use as an abuse. You walk a fine line here. IMHO the kernel keyring is a place where you store information. It is true that based on the information you store there you can take additional actions (in the user space usually). But I think that the gss-ctx usage is overstepping the boundary and using the presence of a key as a trigger to perform actions in the kernel. This is something that is traditionally done via a syscall. My main concern is around things like access control, how is that performed ? Also I think it introduces a lot more code than is needed for the simplest implementation. The simplest implementation in my mind is that the login system can call the syscall no matter what the current status in the kernel and ask the nfs client subsystem to nuke any credentials associated to uid 1234 whether that uid has any credentials on the system or not. So it allows to ignore completely any real tracking and just simply be sure each and all creds associated to that user id are nuked. this could actually be extended beyond NFS, ideally any kernel driver that stores some form of credential or data associated to a specific UID may hook to the syscall to be notified when it is time to blast away the data. Your model seem more fragile in the sense that you need to set up the whole tracking part to, so if you have a bug there you'll end up not removing creds from the kernel. It is also very specific to the NFS client, but that may or may not be an issue. > > Or did I misunderstand what you mean by "telling the kernel to do X" ? > > > >>> This way you can replace the logic of how to keep track of what is > >>> going on completely in user space, where it can easily be adjusted > >>> and adapted as experience is gained. > >>> > >>> IE: track it completely in userspace for now and only provide a > >>> syscall to kill creds per UID, no tracking on the kernel side. > >> > >> Yes - I believe that is what the gss-ctx keyring code I wrote does. > > > > A keyring is not a syscall. > > Yes, but it does as you suggested "provide a downcall to the kernel that will tell it: destroy any > cache for 'uid number" > > What is the disadvantage of using the keyring? Hopefully I answered above. Simo. -- Simo Sorce * Red Hat, Inc * New York -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
