On Nov 22, 2013, at 2:09 PM, Simo Sorce <simo@xxxxxxxxxx> wrote: > 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. OK - I'll look into a syscall. -->Andy > >>> 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
