On Mon, Aug 7, 2017 at 6:27 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Fri, 2017-08-04 at 10:49 -0400, Olga Kornievskaia wrote:
>> Allow a user to call into the file system and ask to destroy FS
>> credentials. For instance, when the user logs out after using
>> a kerberized NFS share, he destroys Kerberos credentials but NFS
>> credentials remain valid until the gss context expires. Allow
>> the user (or things like pam) to trigger destruction of such
>> credentials.
>>
>> A userland application would do:
>>
>> fd = open("/mnt", O_DIRECTORY|O_RDONLY);
>> syscall(_NR_destroy_creds, fd);
>>
>> v2: fixing a hasty IS_DIR check, definition of __NR_destroy_creds
>> and order of the patches
>>
>> Olga Kornievskaia (3):
>> VFS adding destroy_creds call
>> SUNRPC mark user credentials destroyed
>> NFS define vfs destroy_creds functions
>>
>> arch/x86/entry/syscalls/syscall_32.tbl | 1 +
>> arch/x86/entry/syscalls/syscall_64.tbl | 1 +
>> fs/nfs/dir.c | 8 ++++++++
>> fs/read_write.c | 22 ++++++++++++++++++++++
>> include/linux/fs.h | 2 ++
>> include/linux/sunrpc/auth.h | 5 +++++
>> include/linux/syscalls.h | 2 +-
>> include/uapi/asm-generic/unistd.h | 4 +++-
>> kernel/sys_ni.c | 1 +
>> net/sunrpc/auth.c | 9 +++++++++
>> net/sunrpc/auth_generic.c | 15 +++++++++++++++
>> net/sunrpc/auth_gss/auth_gss.c | 3 +++
>> 12 files changed, 71 insertions(+), 2 deletions(-)
>>
>
> I think I'd like to see a proposed manpage for this syscall.
Ok.
> How do you expect this syscall to be used by userland? What will call it
> and under what circumstances?
I think we need to provide flexibility to the userland on how it would
be triggered. It could be that the user runs an application (fslogout
/mnt). AFS has “unlog” for logout I think. But such an application
could also be integrated by an administrated into the logout script
from the shell or it could be integrated into something like pam.
> Also, this looks at first glance like a single-purpose, single-
> filesystem call. Would this have any purpose at all outside of NFS?
> Would this be usable with CIFS or Ceph in some fashion?
NFS has proposed NFS-specific logout mechanism a while back
http://marc.info/?t=138245185000016&r=1&w=2 and at the time it was
suggested that instead of doing a specific mechanism that only NFS
would use why not do a syscall so that other filesystems would use it.
So….
That’s the idea that other filesystem could make use of this
functionality to get rid of their security contexts upon user logout.
In the linux kernel, I don’t see security implementation by CIFS so if
it were to be implemented, I would imagine it would be useful. It’s
rather late for AFS now as it already has its own well established
mechanism.
What I’m not clear on is whether or not a mount point is enough to
specify what creds to get rid off for a generic file system,. CIFS is
Kerberos based so very similar to NFS. I think specifying a share
determines which creds need to go. While not proposing to convert it,
but for something like AFS, unlog takes a cell name so then fslog
could take /afs/cell.name to be specific.
I’m not familiar with Ceph security. According to
http://docs.ceph.com/docs/firefly/rados/operations/auth-intro/, under
the “ceph limitations” it says “The cephx protocol authenticates Ceph
clients and servers to each other. It is not intended to handle
authentication of human users or application programs run on their
behalf.” If that is the case then there is no such thing as a user
logout and thus no need to destroy credentials. If there is
authentication of users where the user proves via some means his
identity via some login application. Then I imagine then there would
be a corresponding logout that the Ceph file system in the kernel
doesn’t know that the user have logged out and it would require user
land driven trigger to get rid of such context. I have also read that
Ceph uses a keyring to store the secret key it is uses for securing
communication with the servers. Then if everything is integrated into
the keyring then again no need for a logout method.
I think this feature is useful for where the filesystem manages its
own security contexts that were bootstrapped via some user land
credentials (such Kerberos).
>
> --
> Jeff Layton <jlayton@xxxxxxxxxx>
> --
> 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
