[RFC v3 0/3] VFS/NFS support to destroy FS credentials

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
 
v3: 
* changing error codes
  in VFS return ENOSYS for when destroy_creds is not defined
  in VFS return EBADF if file descriptor is wrong
  return 0 is success (before I had 1 as success and 0 as failure)
  in SUNRPC patch, when credentials are not found return ENOENT not
    EACCES
* including man page

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(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Filesystems (like NFS) would benefit from an ability to destroy
credentials for the current uid.

Systemcall takes in a file descriptor that's a mount point of the
file system. If a non-directory file descriptor supplied it will
failed with EINVAL. If a bad fd leads to EBADF. And if the file
system doesn't implement destroy_creds, ENOSYS is returned.

Signed-off-by: Olga Kornievskaia <redacted>
---
 arch/x86/entry/syscalls/syscall_32.tbl |  1 +
 arch/x86/entry/syscalls/syscall_64.tbl |  1 +
 fs/read_write.c                        | 22 ++++++++++++++++++++++
 include/linux/fs.h                     |  2 ++
 include/linux/syscalls.h               |  2 +-
 include/uapi/asm-generic/unistd.h      |  4 +++-
 kernel/sys_ni.c                        |  1 +
 7 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
index 448ac21..298e72b 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl

@@ -391,3 +391,4 @@
 382	i386	pkey_free		sys_pkey_free
 383	i386	statx			sys_statx
 384	i386	arch_prctl		sys_arch_prctl			compat_sys_arch_prctl
+385	i386	destroy_creds		sys_destroy_creds

diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
index 5aef183..c8a7e38 100644
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl

@@ -339,6 +339,7 @@
 330	common	pkey_alloc		sys_pkey_alloc
 331	common	pkey_free		sys_pkey_free
 332	common	statx			sys_statx
+333	common	destroy_creds		sys_destroy_creds
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact

diff --git a/fs/read_write.c b/fs/read_write.c
index 0cc7033..f2e169b 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c

@@ -2041,3 +2041,25 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
 	return ret;
 }
 EXPORT_SYMBOL(vfs_dedupe_file_range);
+
+long vfs_destroy_creds(struct file *fd)
+{
+	struct inode *inode = file_inode(fd);
+
+	if (!S_ISDIR(inode->i_mode))
+		return -EINVAL;
+	if (fd->f_op->destroy_creds)
+		return fd->f_op->destroy_creds(fd);
+	return -ENOSYS;
+}
+EXPORT_SYMBOL(vfs_destroy_creds);
+
+SYSCALL_DEFINE1(destroy_creds, int, fd_in)
+{
+	struct fd f_in;
+
+	f_in = fdget(fd_in);
+	if (!f_in.file)
+		return -EBADF;
+	return vfs_destroy_creds(f_in.file);
+}

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 6e1fd5d..882bd40 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h

@@ -1699,6 +1699,7 @@ struct file_operations {
 			u64);
 	ssize_t (*dedupe_file_range)(struct file *, u64, u64, struct file *,
 			u64);
+	int (*destroy_creds)(struct file *);
 } __randomize_layout;
 
 struct inode_operations {

@@ -1773,6 +1774,7 @@ extern int vfs_dedupe_file_range_compare(struct inode *src, loff_t srcoff,
 					 loff_t len, bool *is_same);
 extern int vfs_dedupe_file_range(struct file *file,
 				 struct file_dedupe_range *same);
+extern long vfs_destroy_creds(struct file *fd);
 
 struct super_operations {
    	struct inode *(*alloc_inode)(struct super_block *sb);

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 3cb15ea..3b7b749 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h

@@ -905,5 +905,5 @@ asmlinkage long sys_pkey_mprotect(unsigned long start, size_t len,
 asmlinkage long sys_pkey_free(int pkey);
 asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
 			  unsigned mask, struct statx __user *buffer);
-
+asmlinkage long sys_destroy_creds(int fd_in);
 #endif

diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index 061185a..0ad6a0d 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h

@@ -731,9 +731,11 @@
 __SYSCALL(__NR_pkey_free,     sys_pkey_free)
 #define __NR_statx 291
 __SYSCALL(__NR_statx,     sys_statx)
+#define __NR_destroy_creds 292
+__SYSCALL(__NR_destroy_creds, sys_destroy_creds)
 
 #undef __NR_syscalls
-#define __NR_syscalls 292
+#define __NR_syscalls 293
 
 /*
  * All syscalls below here should go away really,

diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 8acef85..cb9ee0b 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c

@@ -178,6 +178,7 @@ asmlinkage long sys_ni_syscall(void)
 cond_syscall(sys_capget);
 cond_syscall(sys_capset);
 cond_syscall(sys_copy_file_range);
+cond_syscall(sys_destroy_creds);
 
 /* arch-specific weak syscall entries */
 cond_syscall(sys_pciconfig_read);

-- 
1.8.3.1

destroy_creds() is a new system call for destroying file system
credentials. This is usefulf for file systems that manage its
own security contexts that were bootstrapped via some user land
credentials (such as Kerberos).

Signed-off-by: Olga Kornievskaia <redacted>
---
 man2/destroy_creds.2 | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 man2/destroy_creds.2

diff --git a/man2/destroy_creds.2 b/man2/destroy_creds.2
new file mode 100644
index 0000000..7b41c9d
--- /dev/null
+++ b/man2/destroy_creds.2

@@ -0,0 +1,130 @@
+.\"This manpage is Copyright (C) 2015 Olga Kornievskaia <kolga@Netapp.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of
+.\" this manual under the conditions for verbatim copying, provided that
+.\" the entire resulting derived work is distributed under the terms of
+.\" a permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume
+.\" no responsibility for errors or omissions, or for damages resulting
+.\" from the use of the information contained herein.  The author(s) may
+.\" not have taken the same level of care in the production of this
+.\" manual, which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH COPY 2 2017-08-07 "Linux" "Linux Programmer's Manual"
+.SH NAME
+destroy_creds \- destroy current user's file system credentials for a mount point
+.SH SYNOPSIS
+.nf
+.B #include <sys/syscall.h>
+.B #include <unistd.h>
+
+.BI "int destroy_creds(int " fd ");
+.fi
+.SH DESCRIPTION
+The
+.BR destroy ()
+system call performs destruction of file system credentials for the current
+user. It identifies the file system by the supplied file descriptor in
+.I fd
+that represents a mount point.
+
+.SH RETURN VALUE
+Upon successful completion,
+.BR destroy_creds ()
+will return 0.
+
+On error,
+.BR destroy_creds ()
+returns \-1 and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EBADF
+.I fd
+file descriptor is not valid
+.TP
+.B EINVAL
+if the input file descriptor is not a directory
+.TP
+.B ENOENT
+no credentials found
+.TP
+.B EACCES
+unable to access credentials
+.TP
+.B ENOSYS
+file system does not implement destroy_creds() functionality
+.SH VERSIONS
+The
+.BR destroy_creds ()
+system call first appeared in Linux 4.1?.
+.SH CONFORMING TO
+The
+.BR destroy_creds ()
+system call is a nonstandard Linux extension.
+.SH NOTES
+
+.BR destroy_creds ()
+gives filesystems an opportunity to destroy credentials. For instance,
+NFS uses Kerberos credentials stored in Kerberos credential cache to
+create its security contexts that then are stored and managed by the
+kernel. Once the user logs out and destroys Kerberos credentials via
+kdestroy, NFS security contexts associate with that user are valid 
+until they expire. fslogout application such provided by the example
+allows the user driven credential destruction in the file system.
+
+.SH EXAMPLE
+.nf
+#define _GNU_SOURCE
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/syscall.h>
+#include <unistd.h>
+
+static int
+destroy_creds(int fd)
+{
+    return syscall(__NR_destroy_creds, fd);
+}
+
+int
+main(int argc, char **argv)
+{
+    int fd, ret;
+
+    if (argc != 2) {
+        fprintf(stderr, "Usage: %s <mount point>\\n", argv[0]);
+        exit(EXIT_FAILURE);
+    }
+
+    fd = open(argv[1], O_DIRECTORY|O_RDONLY);
+    if (fd == \-1) {
+        perror("open (argv[1])");
+        exit(EXIT_FAILURE);
+    }
+
+    ret = destroy_creds(fd);
+    if (ret == \-1) {
+        perror("destroy_creds");
+        exit(EXIT_FAILURE);
+    }
+
+    close(fd);
+    exit(EXIT_SUCCESS);
+}
+.fi

-- 
1.8.3.1

Provide an API -- rpcauth_key_set_destroy() -- to mark specific
gss user's creds destroyed. Afterwards, these credentials come up
as expired and require new credentials to be established. If
previously the user did a kdestroy, then user has no access to
the nfs mount.

Signed-off-by: Olga Kornievskaia <redacted>
---
 include/linux/sunrpc/auth.h    |  5 +++++
 net/sunrpc/auth.c              |  9 +++++++++
 net/sunrpc/auth_generic.c      | 15 +++++++++++++++
 net/sunrpc/auth_gss/auth_gss.c |  3 +++
 4 files changed, 32 insertions(+)

diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h
index 8fd3504..2ab0bc9 100644
--- a/include/linux/sunrpc/auth.h
+++ b/include/linux/sunrpc/auth.h

@@ -76,6 +76,7 @@ struct rpc_cred {
 #define RPCAUTH_CRED_UPTODATE	1
 #define RPCAUTH_CRED_HASHED	2
 #define RPCAUTH_CRED_NEGATIVE	3
+#define RPCAUTH_CRED_DESTROYED	4
 
 /* rpc_auth au_flags */
 #define RPCAUTH_AUTH_NO_CRKEY_TIMEOUT	0x0001 /* underlying cred has no key timeout */

@@ -136,6 +137,8 @@ struct rpc_authops {
 						struct rpcsec_gss_info *);
 	int			(*key_timeout)(struct rpc_auth *,
 						struct rpc_cred *);
+	int			(*key_destroy)(struct rpc_auth *,
+						struct rpc_cred *);
 };
 
 struct rpc_credops {

@@ -198,6 +201,8 @@ int			rpcauth_get_gssinfo(rpc_authflavor_t,
 void			rpcauth_clear_credcache(struct rpc_cred_cache *);
 int			rpcauth_key_timeout_notify(struct rpc_auth *,
 						struct rpc_cred *);
+int			rpcauth_key_set_destroy(struct rpc_auth *,
+						struct rpc_cred *);
 bool			rpcauth_cred_key_to_expire(struct rpc_auth *, struct rpc_cred *);
 char *			rpcauth_stringify_acceptor(struct rpc_cred *);
 

diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index d2623b9..408452c 100644
--- a/net/sunrpc/auth.c
+++ b/net/sunrpc/auth.c

@@ -357,6 +357,15 @@ struct rpc_auth *
 }
 EXPORT_SYMBOL_GPL(rpcauth_key_timeout_notify);
 
+int
+rpcauth_key_set_destroy(struct rpc_auth *auth, struct rpc_cred *cred)
+{
+	if (!cred->cr_auth->au_ops->key_destroy)
+		return 0;
+	return cred->cr_auth->au_ops->key_destroy(auth, cred);
+}
+EXPORT_SYMBOL_GPL(rpcauth_key_set_destroy);
+
 bool
 rpcauth_cred_key_to_expire(struct rpc_auth *auth, struct rpc_cred *cred)
 {

diff --git a/net/sunrpc/auth_generic.c b/net/sunrpc/auth_generic.c
index f1df983..f1b1088 100644
--- a/net/sunrpc/auth_generic.c
+++ b/net/sunrpc/auth_generic.c

@@ -263,6 +263,20 @@ void rpc_destroy_generic_auth(void)
 	return ret;
 }
 
+static int
+generic_key_destroy(struct rpc_auth *auth, struct rpc_cred *cred)
+{
+	struct auth_cred *acred = &container_of(cred, struct generic_cred,
+						gc_base)->acred;
+	struct rpc_cred *tcred;
+
+	tcred = auth->au_ops->lookup_cred(auth, acred, 0);
+	if (IS_ERR(tcred))
+		return -ENOENT;
+	set_bit(RPCAUTH_CRED_DESTROYED, &tcred->cr_flags);
+	return 0;
+}
+
 static const struct rpc_authops generic_auth_ops = {
 	.owner = THIS_MODULE,
 	.au_name = "Generic",

@@ -270,6 +284,7 @@ void rpc_destroy_generic_auth(void)
 	.lookup_cred = generic_lookup_cred,
 	.crcreate = generic_create_cred,
 	.key_timeout = generic_key_timeout,
+	.key_destroy = generic_key_destroy,
 };
 
 static struct rpc_auth generic_auth = {

diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 9463af4..2c1370a 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c

@@ -1473,6 +1473,9 @@ static void gss_pipe_free(struct gss_pipe *p)
 	if (ret == 0)
 		return ret;
 
+	if (test_bit(RPCAUTH_CRED_DESTROYED, &rc->cr_flags))
+		return 0;
+
 	/* Notify acred users of GSS context expiration timeout */
 	if (test_bit(RPC_CRED_NOTIFY_TIMEOUT, &acred->ac_flags) &&
 	    (gss_key_timeout(rc) != 0)) {

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Define the destroy_creds function for the NFS directory.

Signed-off-by: Olga Kornievskaia <redacted>
---
 fs/nfs/dir.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 3522b12..44f1b1e 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c

@@ -54,6 +54,13 @@
 static loff_t nfs_llseek_dir(struct file *, loff_t, int);
 static void nfs_readdir_clear_array(struct page*);
 
+static int nfs_destroy_creds(struct file *file)
+{
+	struct rpc_auth *auth = NFS_SERVER(file_inode(file))->client->cl_auth;
+
+	return rpcauth_key_set_destroy(auth, rpc_lookup_cred());
+}
+
 const struct file_operations nfs_dir_operations = {
 	.llseek		= nfs_llseek_dir,
 	.read		= generic_read_dir,

@@ -61,6 +68,7 @@
 	.open		= nfs_opendir,
 	.release	= nfs_closedir,
 	.fsync		= nfs_fsync_dir,
+	.destroy_creds	= nfs_destroy_creds,
 };
 
 const struct address_space_operations nfs_dir_aops = {

-- 
1.8.3.1

On Mon, 2017-08-07 at 17:23 -0400, Olga Kornievskaia wrote:

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

It seems like we can afford to be rather cavalier about destroying
creds here. Even if we purge creds for a user that should have remained
valid, we just end up having to re-upcall for them, right?
-- 
Jeff Layton [off-list ref]

You may also want to flush any outstanding dirty data and wait for in-progress
operations.

David

On Wed, Aug 9, 2017 at 8:30 AM, Jeff Layton [off-list ref] wrote:

On Mon, 2017-08-07 at 17:23 -0400, Olga Kornievskaia wrote:

quoted

destroy_creds() is a new system call for destroying file system
credentials. This is usefulf for file systems that manage its
own security contexts that were bootstrapped via some user land
credentials (such as Kerberos).

Signed-off-by: Olga Kornievskaia <redacted>
---
 man2/destroy_creds.2 | 130
+++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 man2/destroy_creds.2

diff --git a/man2/destroy_creds.2 b/man2/destroy_creds.2
new file mode 100644
index 0000000..7b41c9d
--- /dev/null
+++ b/man2/destroy_creds.2

@@ -0,0 +1,130 @@
+.\"This manpage is Copyright (C) 2015 Olga Kornievskaia <kolga@Netap

p.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of
this
+.\" manual provided the copyright notice and this permission notice
are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions
of
+.\" this manual under the conditions for verbatim copying, provided
that
+.\" the entire resulting derived work is distributed under the terms
of
+.\" a permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing,
this
+.\" manual page may be incorrect or out-of-date.  The author(s)
assume
+.\" no responsibility for errors or omissions, or for damages
resulting
+.\" from the use of the information contained herein.  The author(s)
may
+.\" not have taken the same level of care in the production of this
+.\" manual, which is licensed free of charge, as they might when
working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied
by
+.\" the source, must acknowledge the copyright and authors of this
work.
+.\" %%%LICENSE_END
+.\"
+.TH COPY 2 2017-08-07 "Linux" "Linux Programmer's Manual"
+.SH NAME
+destroy_creds \- destroy current user's file system credentials for
a mount point
+.SH SYNOPSIS
+.nf
+.B #include <sys/syscall.h>
+.B #include <unistd.h>
+
+.BI "int destroy_creds(int " fd ");
+.fi
+.SH DESCRIPTION
+The
+.BR destroy ()
+system call performs destruction of file system credentials for the
current
+user. It identifies the file system by the supplied file descriptor
in
+.I fd
+that represents a mount point.
+
+.SH RETURN VALUE
+Upon successful completion,
+.BR destroy_creds ()
+will return 0.
+
+On error,
+.BR destroy_creds ()
+returns \-1 and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EBADF
+.I fd
+file descriptor is not valid
+.TP
+.B EINVAL
+if the input file descriptor is not a directory
+.TP
+.B ENOENT
+no credentials found
+.TP
+.B EACCES
+unable to access credentials
+.TP
+.B ENOSYS
+file system does not implement destroy_creds() functionality
+.SH VERSIONS
+The
+.BR destroy_creds ()
+system call first appeared in Linux 4.1?.
+.SH CONFORMING TO
+The
+.BR destroy_creds ()
+system call is a nonstandard Linux extension.
+.SH NOTES
+
+.BR destroy_creds ()
+gives filesystems an opportunity to destroy credentials. For
instance,
+NFS uses Kerberos credentials stored in Kerberos credential cache to
+create its security contexts that then are stored and managed by the
+kernel. Once the user logs out and destroys Kerberos credentials via
+kdestroy, NFS security contexts associate with that user are valid
+until they expire. fslogout application such provided by the example
+allows the user driven credential destruction in the file system.
+
+.SH EXAMPLE
+.nf
+#define _GNU_SOURCE
+#include <fcntl.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/stat.h>
+#include <sys/syscall.h>
+#include <unistd.h>
+
+static int
+destroy_creds(int fd)
+{
+    return syscall(__NR_destroy_creds, fd);
+}
+
+int
+main(int argc, char **argv)
+{
+    int fd, ret;
+
+    if (argc != 2) {
+        fprintf(stderr, "Usage: %s <mount point>\\n", argv[0]);
+        exit(EXIT_FAILURE);
+    }
+
+    fd = open(argv[1], O_DIRECTORY|O_RDONLY);
+    if (fd == \-1) {
+        perror("open (argv[1])");
+        exit(EXIT_FAILURE);
+    }
+
+    ret = destroy_creds(fd);
+    if (ret == \-1) {
+        perror("destroy_creds");
+        exit(EXIT_FAILURE);
+    }
+
+    close(fd);
+    exit(EXIT_SUCCESS);
+}
+.fi

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

My vision is simple. Provide simple user land application as is and
have it then customized to whatever environment might need it.

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each?

Yes I think this would be a good use case.

Will this be added to kdestroy?

At the time http://marc.info/?l=linux-nfs&m=138246272628823&w=2,
Simo pointed out that adding something to kdestroy was not general
enough as there might be other applications calling krb5 libraries directly
and managing credential cache. He suggested a standalone app that is
used as needed.

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Again wasn't thinking about this due to
http://marc.info/?l=linux-nfs&m=138497973702474&w=2
Greg Hudson wrote:
"Kerberos credential caches can be used for several different purposes;
they aren't only used to store login credentials.  For instance, a user could
run a server process which receives delegated credentials from a client, or
could run admin and get credentials for username/admin to administer the
realm's KDB. Notifying the kernel any time any credential cache is destroyed
would create a lot of false positives. I would be happy to have a pluggable
interface which allows for implementations of new ccache types, but I don't
think I would welcome a hook-style interface which causes ccache operations
to have arbitrary side effects beyond changing the ccache."

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

One example of use that really doesn't deal with user logging out of the
system had to do with scientific computing. In such environment, there is an
infrastructure where runs jobs with different uids and associated with it tgts.
But once the job is done and creds are destroyed, they can't start the new
job until the NFS gss context expires. So kinit, run job, kdestroy, fslogout,
kinit as a different user and run another job.

Again another similar example from use a place that uses microscopes for
large scale data recording. They had a setup where there is a "single user" in
the machine but in reality the human users are multiple (but from what I
understand serialized, one at a time) and when they kinit they store
their creds
in the ticket cache of the "single user". But if the new user logs in
prior to gss
context expiring, the NFS context in the kernel is the one from the old user.

Whether the user land application does a log out of all the mount points or
specific mount points I think should be configurable and something that an
administrator can manipulate.

While I stated that it's too late for AFS to make use of it, but AFS's "unlog"
provides an option to remove creds from a specific cell. But perhaps some
other future FS might want to have an ability to do the same. So doing it
on a per-mount seems the right thing.

It seems like we can afford to be rather cavalier about destroying
creds here. Even if we purge creds for a user that should have remained
valid, we just end up having to re-upcall for them, right?

Correct, if the user didn't destroy kerberos credentials, then fslogout just
invalidates current creds and new creds will be acquired using the ticket cache.

--
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Aug 7, 2017 at 2:23 PM, Olga Kornievskaia [off-list ref] wrote:

Does this mean that whatever credentials are used for the current
*fsuid* are destroyed?  Are there actually per-uid credentials in the
first place?

What privileges, if any, are needed to call this?

What if fd points to a bind mount?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Aug 9, 2017 at 12:08 PM, Andy Lutomirski [off-list ref] wrote:

On Mon, Aug 7, 2017 at 2:23 PM, Olga Kornievskaia [off-list ref] wrote:

quoted

destroy_creds() is a new system call for destroying file system
credentials. This is usefulf for file systems that manage its
own security contexts that were bootstrapped via some user land
credentials (such as Kerberos).

Signed-off-by: Olga Kornievskaia <redacted>
---
 man2/destroy_creds.2 | 130 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 130 insertions(+)
 create mode 100644 man2/destroy_creds.2

diff --git a/man2/destroy_creds.2 b/man2/destroy_creds.2
new file mode 100644
index 0000000..7b41c9d
--- /dev/null
+++ b/man2/destroy_creds.2

@@ -0,0 +1,130 @@
+.\"This manpage is Copyright (C) 2015 Olga Kornievskaia <kolga@Netapp.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of
+.\" this manual under the conditions for verbatim copying, provided that
+.\" the entire resulting derived work is distributed under the terms of
+.\" a permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume
+.\" no responsibility for errors or omissions, or for damages resulting
+.\" from the use of the information contained herein.  The author(s) may
+.\" not have taken the same level of care in the production of this
+.\" manual, which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH COPY 2 2017-08-07 "Linux" "Linux Programmer's Manual"
+.SH NAME
+destroy_creds \- destroy current user's file system credentials for a mount point
+.SH SYNOPSIS
+.nf
+.B #include <sys/syscall.h>
+.B #include <unistd.h>
+
+.BI "int destroy_creds(int " fd ");
+.fi
+.SH DESCRIPTION
+The
+.BR destroy ()
+system call performs destruction of file system credentials for the current
+user. It identifies the file system by the supplied file descriptor in
+.I fd
+that represents a mount point.

Does this mean that whatever credentials are used for the current
*fsuid* are destroyed?

It allows a filesystem to remove in-kernel credentials associated with
the current user (fluid). File system like NFS bootstraps its
in-kernel credentials with credentials stored in the Kerberos ticket
cache. Running example "fslogout" will not remove the Kerberos ticket
cache (which is typically done by running kdestroy).  Running fslogout
without running kdestroy invalidate current in-kernel credentials, but
NFS will acquire new ones using the still existing Kerberos ticket
cache.

Are there actually per-uid credentials in the first place?

For something like NFS yes. AFS and CIFS too. Since no system call
like this was available, AFS has its own mechanism of removing
credentials (unlog). Linux CIFS security is based on Kerberos too but
is not currently implemented. It could benefit from a system call of
this sort.

What privileges, if any, are needed to call this?

No privileges. A file system implementing destroy_creds() should
remove credentials associated with the credentials of the running user
context (fsuid).

What if fd points to a bind mount?

It's just like the original mount. Removing credentials on either
(original or mount) of the mount points will remove credentials for
the user.

On Wed, Aug 9, 2017 at 8:55 AM, David Howells [off-list ref] wrote:

You may also want to flush any outstanding dirty data and wait for in-progress
operations.

Sorry for the delayed response but I've been thinking about it as this
is a tricky one (for me at least).

Even currently, each file system needs a way to deal with flushing
cached data to storage in the situation where creds might have expired
in between when the kernel returned control back to the user but
before all of buffered writes are flushed. NFS4.1 has wording in the
spec for using machine credentials in that case.

At the VFS layer, there no what to tell which dirty data belongs to
which user. Flushing all data under the superblock seems like a bad
idea?

On Thu, Aug 10 2017, Olga Kornievskaia wrote:

On Wed, Aug 9, 2017 at 8:55 AM, David Howells [off-list ref] wrote:

quoted

You may also want to flush any outstanding dirty data and wait for in-progress
operations.

Sorry for the delayed response but I've been thinking about it as this
is a tricky one (for me at least).

Even currently, each file system needs a way to deal with flushing
cached data to storage in the situation where creds might have expired
in between when the kernel returned control back to the user but
before all of buffered writes are flushed. NFS4.1 has wording in the
spec for using machine credentials in that case.

At the VFS layer, there no what to tell which dirty data belongs to
which user. Flushing all data under the superblock seems like a bad
idea?

NFS flushes data when the file descriptor is closed.  So as long as the
user does have any open-for-write file descriptors, their data should be
safe.  Purging credentials while you still have open-for-write file
descriptors is probably not a good idea.

This is not the case if you "nocto" mount option is used, but that is
recommended only for read-mostly mounts.

NeilBrown

On Wed, Aug 09 2017, Jeff Layton wrote:
....

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

Having looked at the code, I think this is invalidating cached
credentials globally -- or at least, globally for all filesystems that
use sunrpc.

I actually question the premise for wanting to do this.  Tickets have a
timeout and will expire.  Any code that is allowed to get a ticket, can
hold on to it as long as it likes - but it will cease to work after the
expiry time.  Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.  If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

What is the threat-model that this change is supposed to guard against?

Looking that the syscall itself:
 1/ why restrict the call to directories only?
 2/ Every new syscall should have a 'flags' argument, because you never
    know when you'll need one.

NeilBrown

   

It seems like we can afford to be rather cavalier about destroying
creds here. Even if we purge creds for a user that should have remained
valid, we just end up having to re-upcall for them, right?
-- 
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:

On Wed, Aug 09 2017, Jeff Layton wrote:
....

quoted

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

Having looked at the code, I think this is invalidating cached
credentials globally -- or at least, globally for all filesystems that
use sunrpc.

I actually question the premise for wanting to do this.  Tickets have a
timeout and will expire.  Any code that is allowed to get a ticket, can
hold on to it as long as it likes - but it will cease to work after the
expiry time.  Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.  If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

What is the threat-model that this change is supposed to guard against?

Looking that the syscall itself:
 1/ why restrict the call to directories only?
 2/ Every new syscall should have a 'flags' argument, because you never
    know when you'll need one.

I have some of the same concerns. For instance, we don't kill off ssh
sessions that were established with krb5 just because the credcache was
destroyed. RPC is a bit different since we authenticate every call, but
is this fundamentally different from keeping an ssh session around that
was established before the credcache was destroyed?

Are we just getting tickets with too long a lifetime here? Maybe we just
need to be more cavalier about destroying cached creds on some event or
on a more timely basis?

Also, the whole gssapi credcache in the kernel is showing its age a bit.
struct auth_cred has had this over it for about as long as I've been
doing kernel work:

    /* Work around the lack of a VFS credential */

We've had struct cred for ages now.

David and I were chatting about this the other day and were wondering if
we could change the RPC gssapi code to cache credentials in one of the
keyrings in struct cred. Then, once the struct cred goes away, the key
would go away as well. It wouldn't be destroyed on kdestroy, but once
the last process with those creds exits, they would go away.

-- 
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Aug 11, 2017, at 3:17 AM, NeilBrown [off-list ref] wrote:

On Wed, Aug 09 2017, Jeff Layton wrote:
....

quoted

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

Having looked at the code, I think this is invalidating cached
credentials globally -- or at least, globally for all filesystems that
use sunrpc.

Yes all filesystems that use sunrpc could benefit from by calling the 
same routine that NFS calls. It only does it per “auth” flavor. If you 
have multiple flavor mounts, only specified one is effected.

I actually question the premise for wanting to do this.  Tickets have a
timeout and will expire.  Any code that is allowed to get a ticket, can
hold on to it as long as it likes - but it will cease to work after the
expiry time.

However, when kdestroy is called, then any code that tries to use it
will yet. User land is unaware that the kernel has cached his 
credentials.

 Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.  

No caching should be valid after credentials were explicitly removed. 

If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

That’s correct. The only means that people who have complained 
about is left with is using short credentials. But security context 
establishment is not for-free and impacts performance.

What is the threat-model that this change is supposed to guard against?

It’s a limitation of a system that I feel has solution of providing the 
extension to kdestroy that destroys FS creds.

What’s the disadvantage of providing this feature? There are folks who 
have been asking for it. It tightens up the security.

Looking that the syscall itself:
1/ why restrict the call to directories only?

No real reason. It seems unlikely that the practical unlog application would 
open a filesystem specific file and then call the unlog on that file. It’ll be
problematic as without creds no close can be done and would leave state
on the server?

2/ Every new syscall should have a 'flags' argument, because you never
   know when you'll need one.

Ok.

NeilBrown

quoted

It seems like we can afford to be rather cavalier about destroying
creds here. Even if we purge creds for a user that should have remained
valid, we just end up having to re-upcall for them, right?
-- 
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Aug 11, 2017 at 7:18 AM, Jeff Layton [off-list ref] wrote:

On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:

quoted

On Wed, Aug 09 2017, Jeff Layton wrote:
....

quoted

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

Having looked at the code, I think this is invalidating cached
credentials globally -- or at least, globally for all filesystems that
use sunrpc.

I actually question the premise for wanting to do this.  Tickets have a
timeout and will expire.  Any code that is allowed to get a ticket, can
hold on to it as long as it likes - but it will cease to work after the
expiry time.  Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.  If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

What is the threat-model that this change is supposed to guard against?

Looking that the syscall itself:
 1/ why restrict the call to directories only?
 2/ Every new syscall should have a 'flags' argument, because you never
    know when you'll need one.

I have some of the same concerns. For instance, we don't kill off ssh
sessions that were established with krb5 just because the credcache was
destroyed. RPC is a bit different since we authenticate every call, but
is this fundamentally different from keeping an ssh session around that
was established before the credcache was destroyed?

Probably because fundamentally, it’s the same user that keeps using it.
If the same ssh connection was shared by multiple users that were inserting
and deleting their credentials then it would be as problematic.

Are we just getting tickets with too long a lifetime here? Maybe we just
need to be more cavalier about destroying cached creds on some event or
on a more timely basis?

Also, the whole gssapi credcache in the kernel is showing its age a bit.
struct auth_cred has had this over it for about as long as I've been
doing kernel work:

    /* Work around the lack of a VFS credential */

We've had struct cred for ages now.

David and I were chatting about this the other day and were wondering if
we could change the RPC gssapi code to cache credentials in one of the
keyrings in struct cred. Then, once the struct cred goes away, the key
would go away as well. It wouldn't be destroyed on kdestroy, but once
the last process with those creds exits, they would go away.

One argument against it: Kerberos has changed their storage location
over the years (FILES … to keyring). What if they change again? Then NFS
would have to change their implementation as well.

Having said that: outside of the fs-mailing list, I have asked Trond that
if VFS decides to reject the syscall idea, what would be an alternative
and one of the choices is the keyring. Of course there are variations of
how the keyring would be used. One option would be to totally switch to
storing credentials in the keyring. To what what Andy had originally
proposed of introducing a gss key type and storing the gss context in
the keyring.

--
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

apologies for duplicates (first attempt bounced from the mailing lists)

On Fri, Aug 11, 2017 at 3:17 AM, NeilBrown [off-list ref] wrote:

On Wed, Aug 09 2017, Jeff Layton wrote:
....

quoted

Thanks, that helps a bit. I'm less clear on what the higher-level
vision is here though:

Are we all going to be running scripts on logout that scrape
/proc/mounts and run fslogout on each? Will this be added to kdestroy?

Or are you aiming to have KCM do this on some trigger? (see:
https://fedoraproject.org/wiki/Changes/KerberosKCMCache)

Also, doing this per-mount seems wrong to me. Shouldn't this be done on
a per-net-namespace basis or maybe even globally?

Having looked at the code, I think this is invalidating cached
credentials globally -- or at least, globally for all filesystems that
use sunrpc.

Yes all filesystems that use sunrpc could benefit from by calling the
same routine that NFS calls. It only does it per “auth” flavor. If you
have multiple flavor mounts, only specified one is effected.

I actually question the premise for wanting to do this.  Tickets have a
timeout and will expire.  Any code that is allowed to get a ticket, can
hold on to it as long as it likes - but it will cease to work after the
expiry time.

However, when kdestroy is called, then any code that tries to use it
will yet. User land is unaware that the kernel has cached his
credentials.

Hunting out all the places that a key might be cached, and
invalidating them, seems to deviate from the model.

No caching should be valid after credentials were explicitly removed.

If you are concerned
about leaving credentials around where they can theoretically be
misused, then set a smaller expiry time.

That’s correct. The only means that people who have complained
about is left with is using short credentials. But security context
establishment is not for-free and impacts performance.

What is the threat-model that this change is supposed to guard against?

It’s a limitation of a system that I feel has solution of providing the
extension to kdestroy that destroys FS creds.

What’s the disadvantage of providing this feature? There are folks who
have been asking for it. It tightens up the security.

Looking that the syscall itself:
 1/ why restrict the call to directories only?

No real reason. It seems unlikely that the practical unlog application would
open a filesystem specific file and then call the unlog on that file. It’ll be
problematic as without creds no close can be done and would leave state
on the server?

 2/ Every new syscall should have a 'flags' argument, because you never
    know when you'll need one.

NeilBrown

quoted

It seems like we can afford to be rather cavalier about destroying
creds here. Even if we purge creds for a user that should have remained
valid, we just end up having to re-upcall for them, right?

Ok.

quoted

--
Jeff Layton [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html