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

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

[Olga Kornievskaia]

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

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

[Olga Kornievskaia]

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

[RFC v3 1/3] VFS adding destroy_creds call

[Olga Kornievskaia]

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 <kolga@netapp.com>
---
 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

[RFC v3 1/3] VFS adding destroy_creds call

[Olga Kornievskaia]

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 <kolga@netapp.com>
---
 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

[RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

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 <kolga@netapp.com>
---
 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

[RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

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 <kolga@netapp.com>
---
 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

[RFC v3 2/3] SUNRPC mark user credentials destroyed

[Olga Kornievskaia]

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 <kolga@netapp.com>
---
 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

[RFC v3 2/3] SUNRPC mark user credentials destroyed

[Olga Kornievskaia]

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 <kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
---
 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

[RFC v3 3/3] NFS define vfs destroy_creds functions

[Olga Kornievskaia]

Define the destroy_creds function for the NFS directory.

Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
---
 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

[RFC v3 3/3] NFS define vfs destroy_creds functions

[Olga Kornievskaia]

Define the destroy_creds function for the NFS directory.

Signed-off-by: Olga Kornievskaia <kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
---
 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Mon, 2017-08-07 at 17:23 -0400, Olga Kornievskaia wrote:
> 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 <kolga@netapp.com>
> ---
>  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:

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 <jlayton@redhat.com>

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

[David Howells]

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

David

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

[David Howells]

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

David

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Wed, Aug 9, 2017 at 8:30 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Mon, 2017-08-07 at 17:23 -0400, Olga Kornievskaia wrote:
>> 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 <kolga@netapp.com>
>> ---
>>  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 <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Wed, Aug 9, 2017 at 8:30 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Mon, 2017-08-07 at 17:23 -0400, Olga Kornievskaia wrote:
>> 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 <kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
>> ---
>>  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 <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Andy Lutomirski]

On Mon, Aug 7, 2017 at 2:23 PM, Olga Kornievskaia <kolga@netapp.com> wrote:
> 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 <kolga@netapp.com>
> ---
>  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?  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?

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Andy Lutomirski]

On Mon, Aug 7, 2017 at 2:23 PM, Olga Kornievskaia <kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org> wrote:
> 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 <kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
> ---
>  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-ZwjVKphTwtPQT0dZR+AlfA@public.gmane.org>
> +.\"
> +.\" %%%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?  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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Wed, Aug 9, 2017 at 12:08 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Aug 7, 2017 at 2:23 PM, Olga Kornievskaia <kolga@netapp.com> wrote:
>> 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 <kolga@netapp.com>
>> ---
>>  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.

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

[Olga Kornievskaia]

On Wed, Aug 9, 2017 at 8:55 AM, David Howells <dhowells@redhat.com> 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?

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

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On Thu, Aug 10 2017, Olga Kornievskaia wrote:

> On Wed, Aug 9, 2017 at 8:55 AM, David Howells <dhowells@redhat.com> 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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Thu, Aug 10 2017, Olga Kornievskaia wrote:

> On Wed, Aug 9, 2017 at 8:55 AM, David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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?

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

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 <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

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 <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
> 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.
> 

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 <jlayton@redhat.com>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
> 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.
> 

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 <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

> On Aug 11, 2017, at 3:17 AM, NeilBrown <neilb@suse.com> wrote:
> 
> 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.

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
> 
> 
>> 
>> 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 <jlayton@redhat.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

> On Aug 11, 2017, at 3:17 AM, NeilBrown <neilb@suse.com> wrote:
>=20
> On Wed, Aug 09 2017, Jeff Layton wrote:
> ....
>>=20
>> Thanks, that helps a bit. I'm less clear on what the higher-level
>> vision is here though:
>>=20
>> 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?
>>=20
>> Or are you aiming to have KCM do this on some trigger? (see:
>> https://fedoraproject.org/wiki/Changes/KerberosKCMCache)
>>=20
>> Also, doing this per-mount seems wrong to me. Shouldn't this be done =
on
>> a per-net-namespace basis or maybe even globally?
>=20
> 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=20
same routine that NFS calls. It only does it per =E2=80=9Cauth=E2=80=9D =
flavor. If you=20
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=20
credentials.

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

No caching should be valid after credentials were explicitly removed.=20

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

That=E2=80=99s correct. The only means that people who have complained=20=

about is left with is using short credentials. But security context=20
establishment is not for-free and impacts performance.

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

It=E2=80=99s a limitation of a system that I feel has solution of =
providing the=20
extension to kdestroy that destroys FS creds.

What=E2=80=99s the disadvantage of providing this feature? There are =
folks who=20
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=20
open a filesystem specific file and then call the unlog on that file. =
It=E2=80=99ll 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.

>=20
> NeilBrown
>=20
>=20
>>=20
>> 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?
>> --=20
>> Jeff Layton <jlayton@redhat.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

> On Aug 11, 2017, at 3:17 AM, NeilBrown <neilb-IBi9RG/b67k@public.gmane.org> wrote:
> 
> 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.

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
> 
> 
>> 
>> 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 <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> --
>> 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Fri, Aug 11, 2017 at 7:18 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
>> 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.
>>
>
> 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 <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Fri, Aug 11, 2017 at 7:18 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
>> 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 o=
n
>> > 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 concerne=
d
>> 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=E2=80=99s 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 =E2=80=A6 to keyring). What if they change again? The=
n 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 <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Fri, Aug 11, 2017 at 7:18 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
>> 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.
>>
>
> 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 <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

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

On Fri, Aug 11, 2017 at 3:17 AM, NeilBrown <neilb@suse.com> wrote:
> 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.

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
>
>
>>
>> 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.

>> --
>> Jeff Layton <jlayton@redhat.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

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

On Fri, Aug 11, 2017 at 3:17 AM, NeilBrown <neilb@suse.com> wrote:
> 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.

Yes all filesystems that use sunrpc could benefit from by calling the
same routine that NFS calls. It only does it per =E2=80=9Cauth=E2=80=9D fla=
vor. 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=E2=80=99s 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=E2=80=99s a limitation of a system that I feel has solution of providing=
 the
extension to kdestroy that destroys FS creds.

What=E2=80=99s 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 woul=
d
open a filesystem specific file and then call the unlog on that file. It=E2=
=80=99ll 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
>
>
>>
>> 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.

>> --
>> Jeff Layton <jlayton@redhat.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

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

On Fri, Aug 11, 2017 at 3:17 AM, NeilBrown <neilb-IBi9RG/b67k@public.gmane.org> wrote:
> 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.

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
>
>
>>
>> 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.

>> --
>> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> --
>> 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 09:49 -0400, Olga Kornievskaia wrote:
> > On Aug 11, 2017, at 7:18 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > 
> > On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
> > > 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.
> > > 
> > 
> > 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.
> 
> 

I think I wasn't clear here. I'm not proposing that you move everyone to
KEYRING: credcaches. This would not be a visible change to userland.
We'd still use rpc.gssd to upcall for creds.

What I'm saying is that instead of storing the creds in a hashtable like
we do today, we'd just stash them in one of the keyrings hanging off of
struct cred.

Change all of the authgss_ops operations to do query/store from the
appropriate keyring directly. With that, the effective lifetime of
GSSAPI creds would be bounded by the lifetime of the keyrings that hold
references to it.

We'd probably need a new key_type for this to ensure that this couldn't
be manipulated directly from userland. Or...maybe you'd still want to
allow userland to destroy the creds? No need for a new syscall with that
-- they can just do a "keyctl unlink". There are a lot of options here.

It's a non-trivial amount of work though (rpcauth_lookupcred() on down
would probably need to be reworked) and I haven't looked at it detail.
Still, it seems like it could be a more modern and cleaner design than
what we have today.

-- 
Jeff Layton <jlayton@redhat.com>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 09:49 -0400, Olga Kornievskaia wrote:
> > On Aug 11, 2017, at 7:18 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> > On Fri, 2017-08-11 at 17:17 +1000, NeilBrown wrote:
> > > 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.
> > > 
> > 
> > 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.
> 
> 

I think I wasn't clear here. I'm not proposing that you move everyone to
KEYRING: credcaches. This would not be a visible change to userland.
We'd still use rpc.gssd to upcall for creds.

What I'm saying is that instead of storing the creds in a hashtable like
we do today, we'd just stash them in one of the keyrings hanging off of
struct cred.

Change all of the authgss_ops operations to do query/store from the
appropriate keyring directly. With that, the effective lifetime of
GSSAPI creds would be bounded by the lifetime of the keyrings that hold
references to it.

We'd probably need a new key_type for this to ensure that this couldn't
be manipulated directly from userland. Or...maybe you'd still want to
allow userland to destroy the creds? No need for a new syscall with that
-- they can just do a "keyctl unlink". There are a lot of options here.

It's a non-trivial amount of work though (rpcauth_lookupcred() on down
would probably need to be reworked) and I haven't looked at it detail.
Still, it seems like it could be a more modern and cleaner design than
what we have today.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Trond Myklebust]

On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> I think I wasn't clear here. I'm not proposing that you move everyone
> to
> KEYRING: credcaches. This would not be a visible change to userland.
> We'd still use rpc.gssd to upcall for creds.
> 
> What I'm saying is that instead of storing the creds in a hashtable
> like
> we do today, we'd just stash them in one of the keyrings hanging off
> of
> struct cred.
> 
> Change all of the authgss_ops operations to do query/store from the
> appropriate keyring directly. With that, the effective lifetime of
> GSSAPI creds would be bounded by the lifetime of the keyrings that
> hold
> references to it.
> 
> We'd probably need a new key_type for this to ensure that this
> couldn't
> be manipulated directly from userland. Or...maybe you'd still want to
> allow userland to destroy the creds? No need for a new syscall with
> that
> -- they can just do a "keyctl unlink". There are a lot of options
> here.
> 
> It's a non-trivial amount of work though (rpcauth_lookupcred() on
> down
> would probably need to be reworked) and I haven't looked at it
> detail.
> Still, it seems like it could be a more modern and cleaner design
> than
> what we have today.
> 

The main annoyance with going from a global to a local cache such as
the keyrings is that it makes comparing credentials a lot more work.
Today, because the credentials are essentially unique per server, we
just do pointer comparisons. Once we have non-global caches, we would
need to do more elaborate comparisons to ensure that the uid, gid, and
list of groups match.
That's also why we never made the leap to using 'struct cred', btw...

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Trond Myklebust]

T24gRnJpLCAyMDE3LTA4LTExIGF0IDEwOjIyIC0wNDAwLCBKZWZmIExheXRvbiB3cm90ZToNCj4g
SSB0aGluayBJIHdhc24ndCBjbGVhciBoZXJlLiBJJ20gbm90IHByb3Bvc2luZyB0aGF0IHlvdSBt
b3ZlIGV2ZXJ5b25lDQo+IHRvDQo+IEtFWVJJTkc6IGNyZWRjYWNoZXMuIFRoaXMgd291bGQgbm90
IGJlIGEgdmlzaWJsZSBjaGFuZ2UgdG8gdXNlcmxhbmQuDQo+IFdlJ2Qgc3RpbGwgdXNlIHJwYy5n
c3NkIHRvIHVwY2FsbCBmb3IgY3JlZHMuDQo+IA0KPiBXaGF0IEknbSBzYXlpbmcgaXMgdGhhdCBp
bnN0ZWFkIG9mIHN0b3JpbmcgdGhlIGNyZWRzIGluIGEgaGFzaHRhYmxlDQo+IGxpa2UNCj4gd2Ug
ZG8gdG9kYXksIHdlJ2QganVzdCBzdGFzaCB0aGVtIGluIG9uZSBvZiB0aGUga2V5cmluZ3MgaGFu
Z2luZyBvZmYNCj4gb2YNCj4gc3RydWN0IGNyZWQuDQo+IA0KPiBDaGFuZ2UgYWxsIG9mIHRoZSBh
dXRoZ3NzX29wcyBvcGVyYXRpb25zIHRvIGRvIHF1ZXJ5L3N0b3JlIGZyb20gdGhlDQo+IGFwcHJv
cHJpYXRlIGtleXJpbmcgZGlyZWN0bHkuIFdpdGggdGhhdCwgdGhlIGVmZmVjdGl2ZSBsaWZldGlt
ZSBvZg0KPiBHU1NBUEkgY3JlZHMgd291bGQgYmUgYm91bmRlZCBieSB0aGUgbGlmZXRpbWUgb2Yg
dGhlIGtleXJpbmdzIHRoYXQNCj4gaG9sZA0KPiByZWZlcmVuY2VzIHRvIGl0Lg0KPiANCj4gV2Un
ZCBwcm9iYWJseSBuZWVkIGEgbmV3IGtleV90eXBlIGZvciB0aGlzIHRvIGVuc3VyZSB0aGF0IHRo
aXMNCj4gY291bGRuJ3QNCj4gYmUgbWFuaXB1bGF0ZWQgZGlyZWN0bHkgZnJvbSB1c2VybGFuZC4g
T3IuLi5tYXliZSB5b3UnZCBzdGlsbCB3YW50IHRvDQo+IGFsbG93IHVzZXJsYW5kIHRvIGRlc3Ry
b3kgdGhlIGNyZWRzPyBObyBuZWVkIGZvciBhIG5ldyBzeXNjYWxsIHdpdGgNCj4gdGhhdA0KPiAt
LSB0aGV5IGNhbiBqdXN0IGRvIGEgImtleWN0bCB1bmxpbmsiLiBUaGVyZSBhcmUgYSBsb3Qgb2Yg
b3B0aW9ucw0KPiBoZXJlLg0KPiANCj4gSXQncyBhIG5vbi10cml2aWFsIGFtb3VudCBvZiB3b3Jr
IHRob3VnaCAocnBjYXV0aF9sb29rdXBjcmVkKCkgb24NCj4gZG93bg0KPiB3b3VsZCBwcm9iYWJs
eSBuZWVkIHRvIGJlIHJld29ya2VkKSBhbmQgSSBoYXZlbid0IGxvb2tlZCBhdCBpdA0KPiBkZXRh
aWwuDQo+IFN0aWxsLCBpdCBzZWVtcyBsaWtlIGl0IGNvdWxkIGJlIGEgbW9yZSBtb2Rlcm4gYW5k
IGNsZWFuZXIgZGVzaWduDQo+IHRoYW4NCj4gd2hhdCB3ZSBoYXZlIHRvZGF5Lg0KPiANCg0KVGhl
IG1haW4gYW5ub3lhbmNlIHdpdGggZ29pbmcgZnJvbSBhIGdsb2JhbCB0byBhIGxvY2FsIGNhY2hl
IHN1Y2ggYXMNCnRoZSBrZXlyaW5ncyBpcyB0aGF0IGl0IG1ha2VzIGNvbXBhcmluZyBjcmVkZW50
aWFscyBhIGxvdCBtb3JlIHdvcmsuDQpUb2RheSwgYmVjYXVzZSB0aGUgY3JlZGVudGlhbHMgYXJl
IGVzc2VudGlhbGx5IHVuaXF1ZSBwZXIgc2VydmVyLCB3ZQ0KanVzdCBkbyBwb2ludGVyIGNvbXBh
cmlzb25zLiBPbmNlIHdlIGhhdmUgbm9uLWdsb2JhbCBjYWNoZXMsIHdlIHdvdWxkDQpuZWVkIHRv
IGRvIG1vcmUgZWxhYm9yYXRlIGNvbXBhcmlzb25zIHRvIGVuc3VyZSB0aGF0IHRoZSB1aWQsIGdp
ZCwgYW5kDQpsaXN0IG9mIGdyb3VwcyBtYXRjaC4NClRoYXQncyBhbHNvIHdoeSB3ZSBuZXZlciBt
YWRlIHRoZSBsZWFwIHRvIHVzaW5nICdzdHJ1Y3QgY3JlZCcsIGJ0dy4uLg0KDQotLSANClRyb25k
IE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJv
bmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Trond Myklebust]

On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> I think I wasn't clear here. I'm not proposing that you move everyone
> to
> KEYRING: credcaches. This would not be a visible change to userland.
> We'd still use rpc.gssd to upcall for creds.
> 
> What I'm saying is that instead of storing the creds in a hashtable
> like
> we do today, we'd just stash them in one of the keyrings hanging off
> of
> struct cred.
> 
> Change all of the authgss_ops operations to do query/store from the
> appropriate keyring directly. With that, the effective lifetime of
> GSSAPI creds would be bounded by the lifetime of the keyrings that
> hold
> references to it.
> 
> We'd probably need a new key_type for this to ensure that this
> couldn't
> be manipulated directly from userland. Or...maybe you'd still want to
> allow userland to destroy the creds? No need for a new syscall with
> that
> -- they can just do a "keyctl unlink". There are a lot of options
> here.
> 
> It's a non-trivial amount of work though (rpcauth_lookupcred() on
> down
> would probably need to be reworked) and I haven't looked at it
> detail.
> Still, it seems like it could be a more modern and cleaner design
> than
> what we have today.
> 

The main annoyance with going from a global to a local cache such as
the keyrings is that it makes comparing credentials a lot more work.
Today, because the credentials are essentially unique per server, we
just do pointer comparisons. Once we have non-global caches, we would
need to do more elaborate comparisons to ensure that the uid, gid, and
list of groups match.
That's also why we never made the leap to using 'struct cred', btw...

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
> On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> > I think I wasn't clear here. I'm not proposing that you move everyone
> > to
> > KEYRING: credcaches. This would not be a visible change to userland.
> > We'd still use rpc.gssd to upcall for creds.
> > 
> > What I'm saying is that instead of storing the creds in a hashtable
> > like
> > we do today, we'd just stash them in one of the keyrings hanging off
> > of
> > struct cred.
> > 
> > Change all of the authgss_ops operations to do query/store from the
> > appropriate keyring directly. With that, the effective lifetime of
> > GSSAPI creds would be bounded by the lifetime of the keyrings that
> > hold
> > references to it.
> > 
> > We'd probably need a new key_type for this to ensure that this
> > couldn't
> > be manipulated directly from userland. Or...maybe you'd still want to
> > allow userland to destroy the creds? No need for a new syscall with
> > that
> > -- they can just do a "keyctl unlink". There are a lot of options
> > here.
> > 
> > It's a non-trivial amount of work though (rpcauth_lookupcred() on
> > down
> > would probably need to be reworked) and I haven't looked at it
> > detail.
> > Still, it seems like it could be a more modern and cleaner design
> > than
> > what we have today.
> > 
> 
> The main annoyance with going from a global to a local cache such as
> the keyrings is that it makes comparing credentials a lot more work.
> Today, because the credentials are essentially unique per server, we
> just do pointer comparisons. Once we have non-global caches, we would
> need to do more elaborate comparisons to ensure that the uid, gid, and
> list of groups match.
> That's also why we never made the leap to using 'struct cred', btw...


Ok, it does seem better to have a global cache from that standpoint.
Still, a new syscall for this doesn't seem very elegant. I also worry a
bit about writeback here too (like David and Neil have pointed out).

What about changing how we hold references on these objects instead?

After we look up an auth token in e.g. rpcauth_lookupcred, take a
reference to it and stash a pointer to it somewhere in the cred.
Possibly in the thread or process keyrings, but it may work better
elsewhere.

When we go to look up creds from that thread in the future, we can get
to it directly (which is a nice bonus). When the cred is destroyed
(usually on process destruction), we'd drop the reference to the object,
which would drop the reference to the global cache object.

The global cache could then be changed to have a pretty short timeout (a
few seconds?) and reap the object soon afterward when there are no more
active processes that have used it.

It's a bit more work and we might need to grow struct cred to handle it
(maybe give it its own keyring?), but it seems like that might be a
cleaner solution than giving userland knobs to manage the kernel's
caches.
-- 
Jeff Layton <jlayton@redhat.com>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
> On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> > I think I wasn't clear here. I'm not proposing that you move everyone
> > to
> > KEYRING: credcaches. This would not be a visible change to userland.
> > We'd still use rpc.gssd to upcall for creds.
> > 
> > What I'm saying is that instead of storing the creds in a hashtable
> > like
> > we do today, we'd just stash them in one of the keyrings hanging off
> > of
> > struct cred.
> > 
> > Change all of the authgss_ops operations to do query/store from the
> > appropriate keyring directly. With that, the effective lifetime of
> > GSSAPI creds would be bounded by the lifetime of the keyrings that
> > hold
> > references to it.
> > 
> > We'd probably need a new key_type for this to ensure that this
> > couldn't
> > be manipulated directly from userland. Or...maybe you'd still want to
> > allow userland to destroy the creds? No need for a new syscall with
> > that
> > -- they can just do a "keyctl unlink". There are a lot of options
> > here.
> > 
> > It's a non-trivial amount of work though (rpcauth_lookupcred() on
> > down
> > would probably need to be reworked) and I haven't looked at it
> > detail.
> > Still, it seems like it could be a more modern and cleaner design
> > than
> > what we have today.
> > 
> 
> The main annoyance with going from a global to a local cache such as
> the keyrings is that it makes comparing credentials a lot more work.
> Today, because the credentials are essentially unique per server, we
> just do pointer comparisons. Once we have non-global caches, we would
> need to do more elaborate comparisons to ensure that the uid, gid, and
> list of groups match.
> That's also why we never made the leap to using 'struct cred', btw...


Ok, it does seem better to have a global cache from that standpoint.
Still, a new syscall for this doesn't seem very elegant. I also worry a
bit about writeback here too (like David and Neil have pointed out).

What about changing how we hold references on these objects instead?

After we look up an auth token in e.g. rpcauth_lookupcred, take a
reference to it and stash a pointer to it somewhere in the cred.
Possibly in the thread or process keyrings, but it may work better
elsewhere.

When we go to look up creds from that thread in the future, we can get
to it directly (which is a nice bonus). When the cred is destroyed
(usually on process destruction), we'd drop the reference to the object,
which would drop the reference to the global cache object.

The global cache could then be changed to have a pretty short timeout (a
few seconds?) and reap the object soon afterward when there are no more
active processes that have used it.

It's a bit more work and we might need to grow struct cred to handle it
(maybe give it its own keyring?), but it seems like that might be a
cleaner solution than giving userland knobs to manage the kernel's
caches.
-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Sun, Aug 13, 2017 at 7:38 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
>> On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
>> > I think I wasn't clear here. I'm not proposing that you move everyone
>> > to
>> > KEYRING: credcaches. This would not be a visible change to userland.
>> > We'd still use rpc.gssd to upcall for creds.
>> >
>> > What I'm saying is that instead of storing the creds in a hashtable
>> > like
>> > we do today, we'd just stash them in one of the keyrings hanging off
>> > of
>> > struct cred.
>> >
>> > Change all of the authgss_ops operations to do query/store from the
>> > appropriate keyring directly. With that, the effective lifetime of
>> > GSSAPI creds would be bounded by the lifetime of the keyrings that
>> > hold
>> > references to it.
>> >
>> > We'd probably need a new key_type for this to ensure that this
>> > couldn't
>> > be manipulated directly from userland. Or...maybe you'd still want to
>> > allow userland to destroy the creds? No need for a new syscall with
>> > that
>> > -- they can just do a "keyctl unlink". There are a lot of options
>> > here.
>> >
>> > It's a non-trivial amount of work though (rpcauth_lookupcred() on
>> > down
>> > would probably need to be reworked) and I haven't looked at it
>> > detail.
>> > Still, it seems like it could be a more modern and cleaner design
>> > than
>> > what we have today.
>> >
>>
>> The main annoyance with going from a global to a local cache such as
>> the keyrings is that it makes comparing credentials a lot more work.
>> Today, because the credentials are essentially unique per server, we
>> just do pointer comparisons. Once we have non-global caches, we would
>> need to do more elaborate comparisons to ensure that the uid, gid, and
>> list of groups match.
>> That's also why we never made the leap to using 'struct cred', btw...
>
>
> Ok, it does seem better to have a global cache from that standpoint.
> Still, a new syscall for this doesn't seem very elegant. I also worry a
> bit about writeback here too (like David and Neil have pointed out).
>
> What about changing how we hold references on these objects instead?
>
> After we look up an auth token in e.g. rpcauth_lookupcred, take a
> reference to it and stash a pointer to it somewhere in the cred.
> Possibly in the thread or process keyrings, but it may work better
> elsewhere.
>
> When we go to look up creds from that thread in the future, we can get
> to it directly (which is a nice bonus). When the cred is destroyed
> (usually on process destruction), we'd drop the reference to the object,
> which would drop the reference to the global cache object.
>
> The global cache could then be changed to have a pretty short timeout (a
> few seconds?) and reap the object soon afterward when there are no more
> active processes that have used it.

Wouldn’t that produce a lot of unnecessary context re-establishments.

> It's a bit more work and we might need to grow struct cred to handle it
> (maybe give it its own keyring?), but it seems like that might be a
> cleaner solution than giving userland knobs to manage the kernel's
> caches.

Userland is the only place that know that kdestroy ran and is the best
place to tell the kernel to remove its cache. Everything else is guessing.

> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Sun, Aug 13, 2017 at 7:38 AM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
>> On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
>> > I think I wasn't clear here. I'm not proposing that you move everyone
>> > to
>> > KEYRING: credcaches. This would not be a visible change to userland.
>> > We'd still use rpc.gssd to upcall for creds.
>> >
>> > What I'm saying is that instead of storing the creds in a hashtable
>> > like
>> > we do today, we'd just stash them in one of the keyrings hanging off
>> > of
>> > struct cred.
>> >
>> > Change all of the authgss_ops operations to do query/store from the
>> > appropriate keyring directly. With that, the effective lifetime of
>> > GSSAPI creds would be bounded by the lifetime of the keyrings that
>> > hold
>> > references to it.
>> >
>> > We'd probably need a new key_type for this to ensure that this
>> > couldn't
>> > be manipulated directly from userland. Or...maybe you'd still want to
>> > allow userland to destroy the creds? No need for a new syscall with
>> > that
>> > -- they can just do a "keyctl unlink". There are a lot of options
>> > here.
>> >
>> > It's a non-trivial amount of work though (rpcauth_lookupcred() on
>> > down
>> > would probably need to be reworked) and I haven't looked at it
>> > detail.
>> > Still, it seems like it could be a more modern and cleaner design
>> > than
>> > what we have today.
>> >
>>
>> The main annoyance with going from a global to a local cache such as
>> the keyrings is that it makes comparing credentials a lot more work.
>> Today, because the credentials are essentially unique per server, we
>> just do pointer comparisons. Once we have non-global caches, we would
>> need to do more elaborate comparisons to ensure that the uid, gid, and
>> list of groups match.
>> That's also why we never made the leap to using 'struct cred', btw...
>
>
> Ok, it does seem better to have a global cache from that standpoint.
> Still, a new syscall for this doesn't seem very elegant. I also worry a
> bit about writeback here too (like David and Neil have pointed out).
>
> What about changing how we hold references on these objects instead?
>
> After we look up an auth token in e.g. rpcauth_lookupcred, take a
> reference to it and stash a pointer to it somewhere in the cred.
> Possibly in the thread or process keyrings, but it may work better
> elsewhere.
>
> When we go to look up creds from that thread in the future, we can get
> to it directly (which is a nice bonus). When the cred is destroyed
> (usually on process destruction), we'd drop the reference to the object,
> which would drop the reference to the global cache object.
>
> The global cache could then be changed to have a pretty short timeout (a
> few seconds?) and reap the object soon afterward when there are no more
> active processes that have used it.

Wouldn=E2=80=99t that produce a lot of unnecessary context re-establishment=
s.

> It's a bit more work and we might need to grow struct cred to handle it
> (maybe give it its own keyring?), but it seems like that might be a
> cleaner solution than giving userland knobs to manage the kernel's
> caches.

Userland is the only place that know that kdestroy ran and is the best
place to tell the kernel to remove its cache. Everything else is guessing.

> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Olga Kornievskaia]

On Sun, Aug 13, 2017 at 7:38 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
>> On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
>> > I think I wasn't clear here. I'm not proposing that you move everyone
>> > to
>> > KEYRING: credcaches. This would not be a visible change to userland.
>> > We'd still use rpc.gssd to upcall for creds.
>> >
>> > What I'm saying is that instead of storing the creds in a hashtable
>> > like
>> > we do today, we'd just stash them in one of the keyrings hanging off
>> > of
>> > struct cred.
>> >
>> > Change all of the authgss_ops operations to do query/store from the
>> > appropriate keyring directly. With that, the effective lifetime of
>> > GSSAPI creds would be bounded by the lifetime of the keyrings that
>> > hold
>> > references to it.
>> >
>> > We'd probably need a new key_type for this to ensure that this
>> > couldn't
>> > be manipulated directly from userland. Or...maybe you'd still want to
>> > allow userland to destroy the creds? No need for a new syscall with
>> > that
>> > -- they can just do a "keyctl unlink". There are a lot of options
>> > here.
>> >
>> > It's a non-trivial amount of work though (rpcauth_lookupcred() on
>> > down
>> > would probably need to be reworked) and I haven't looked at it
>> > detail.
>> > Still, it seems like it could be a more modern and cleaner design
>> > than
>> > what we have today.
>> >
>>
>> The main annoyance with going from a global to a local cache such as
>> the keyrings is that it makes comparing credentials a lot more work.
>> Today, because the credentials are essentially unique per server, we
>> just do pointer comparisons. Once we have non-global caches, we would
>> need to do more elaborate comparisons to ensure that the uid, gid, and
>> list of groups match.
>> That's also why we never made the leap to using 'struct cred', btw...
>
>
> Ok, it does seem better to have a global cache from that standpoint.
> Still, a new syscall for this doesn't seem very elegant. I also worry a
> bit about writeback here too (like David and Neil have pointed out).
>
> What about changing how we hold references on these objects instead?
>
> After we look up an auth token in e.g. rpcauth_lookupcred, take a
> reference to it and stash a pointer to it somewhere in the cred.
> Possibly in the thread or process keyrings, but it may work better
> elsewhere.
>
> When we go to look up creds from that thread in the future, we can get
> to it directly (which is a nice bonus). When the cred is destroyed
> (usually on process destruction), we'd drop the reference to the object,
> which would drop the reference to the global cache object.
>
> The global cache could then be changed to have a pretty short timeout (a
> few seconds?) and reap the object soon afterward when there are no more
> active processes that have used it.

Wouldn’t that produce a lot of unnecessary context re-establishments.

> It's a bit more work and we might need to grow struct cred to handle it
> (maybe give it its own keyring?), but it seems like that might be a
> cleaner solution than giving userland knobs to manage the kernel's
> caches.

Userland is the only place that know that kdestroy ran and is the best
place to tell the kernel to remove its cache. Everything else is guessing.

> --
> Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> --
> 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

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Mon, 2017-08-14 at 11:15 -0400, Olga Kornievskaia wrote:
> > On Aug 13, 2017, at 7:38 AM, Jeff Layton <jlayton@redhat.com> wrote:
> > 
> > On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
> > > On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> > > > I think I wasn't clear here. I'm not proposing that you move everyone
> > > > to
> > > > KEYRING: credcaches. This would not be a visible change to userland.
> > > > We'd still use rpc.gssd to upcall for creds.
> > > > 
> > > > What I'm saying is that instead of storing the creds in a hashtable
> > > > like
> > > > we do today, we'd just stash them in one of the keyrings hanging off
> > > > of
> > > > struct cred.
> > > > 
> > > > Change all of the authgss_ops operations to do query/store from the
> > > > appropriate keyring directly. With that, the effective lifetime of
> > > > GSSAPI creds would be bounded by the lifetime of the keyrings that
> > > > hold
> > > > references to it.
> > > > 
> > > > We'd probably need a new key_type for this to ensure that this
> > > > couldn't
> > > > be manipulated directly from userland. Or...maybe you'd still want to
> > > > allow userland to destroy the creds? No need for a new syscall with
> > > > that
> > > > -- they can just do a "keyctl unlink". There are a lot of options
> > > > here.
> > > > 
> > > > It's a non-trivial amount of work though (rpcauth_lookupcred() on
> > > > down
> > > > would probably need to be reworked) and I haven't looked at it
> > > > detail.
> > > > Still, it seems like it could be a more modern and cleaner design
> > > > than
> > > > what we have today.
> > > > 
> > > 
> > > The main annoyance with going from a global to a local cache such as
> > > the keyrings is that it makes comparing credentials a lot more work.
> > > Today, because the credentials are essentially unique per server, we
> > > just do pointer comparisons. Once we have non-global caches, we would
> > > need to do more elaborate comparisons to ensure that the uid, gid, and
> > > list of groups match.
> > > That's also why we never made the leap to using 'struct cred', btw...
> > 
> > Ok, it does seem better to have a global cache from that standpoint.
> > Still, a new syscall for this doesn't seem very elegant. I also worry a
> > bit about writeback here too (like David and Neil have pointed out).
> > 
> > What about changing how we hold references on these objects instead?
> > 
> > After we look up an auth token in e.g. rpcauth_lookupcred, take a
> > reference to it and stash a pointer to it somewhere in the cred.
> > Possibly in the thread or process keyrings, but it may work better
> > elsewhere.
> > 
> > When we go to look up creds from that thread in the future, we can get
> > to it directly (which is a nice bonus). When the cred is destroyed
> > (usually on process destruction), we'd drop the reference to the object,
> > which would drop the reference to the global cache object.
> > 
> > The global cache could then be changed to have a pretty short timeout (a
> > few seconds?) and reap the object soon afterward when there are no more
> > active processes that have used it.
> 
> Wouldn’t that produce a lot of unnecessary context re-establishments. 
> 

I wouldn't think so.

As long as there is an outstanding struct cred that holds a reference to
the rpc cred, then the context will stick around and you shouldn't need
to upcall. Even if all you have is short-lived tasks, you still will
only need to upcall at the rate of the cache timeout, at the max.

Granted, timing out caches like this is a bit of a black art, and I'm
assuming that a small delay (<1 minute) between struct cred destruction
and the context destruction would be ok.

> > It's a bit more work and we might need to grow struct cred to handle it
> > (maybe give it its own keyring?), but it seems like that might be a
> > cleaner solution than giving userland knobs to manage the kernel's
> > caches.
> 
> Userland is the only place that know that kdestroy ran and is the best
> place to tell the kernel to remove its cache. Everything else is guessing.

This doesn't necessarily preclude destroying them manually. If you store
the key in a keyring you could still manually purge that reference with
a keyctl_unlink(). This approach would also mean you wouldn't need a new
syscall as well.

Regardless...I think there is a lot of mileage to be gained out of
handling cache timeouts intelligently. If for no other reason than to
have sane context timeouts for environments that can't or won't call
destroy the creds when the cache is destroyed.

-- 
Jeff Layton <jlayton@redhat.com>

Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()

[Jeff Layton]

On Mon, 2017-08-14 at 11:15 -0400, Olga Kornievskaia wrote:
> > On Aug 13, 2017, at 7:38 AM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> > On Fri, 2017-08-11 at 15:12 +0000, Trond Myklebust wrote:
> > > On Fri, 2017-08-11 at 10:22 -0400, Jeff Layton wrote:
> > > > I think I wasn't clear here. I'm not proposing that you move everyone
> > > > to
> > > > KEYRING: credcaches. This would not be a visible change to userland.
> > > > We'd still use rpc.gssd to upcall for creds.
> > > > 
> > > > What I'm saying is that instead of storing the creds in a hashtable
> > > > like
> > > > we do today, we'd just stash them in one of the keyrings hanging off
> > > > of
> > > > struct cred.
> > > > 
> > > > Change all of the authgss_ops operations to do query/store from the
> > > > appropriate keyring directly. With that, the effective lifetime of
> > > > GSSAPI creds would be bounded by the lifetime of the keyrings that
> > > > hold
> > > > references to it.
> > > > 
> > > > We'd probably need a new key_type for this to ensure that this
> > > > couldn't
> > > > be manipulated directly from userland. Or...maybe you'd still want to
> > > > allow userland to destroy the creds? No need for a new syscall with
> > > > that
> > > > -- they can just do a "keyctl unlink". There are a lot of options
> > > > here.
> > > > 
> > > > It's a non-trivial amount of work though (rpcauth_lookupcred() on
> > > > down
> > > > would probably need to be reworked) and I haven't looked at it
> > > > detail.
> > > > Still, it seems like it could be a more modern and cleaner design
> > > > than
> > > > what we have today.
> > > > 
> > > 
> > > The main annoyance with going from a global to a local cache such as
> > > the keyrings is that it makes comparing credentials a lot more work.
> > > Today, because the credentials are essentially unique per server, we
> > > just do pointer comparisons. Once we have non-global caches, we would
> > > need to do more elaborate comparisons to ensure that the uid, gid, and
> > > list of groups match.
> > > That's also why we never made the leap to using 'struct cred', btw...
> > 
> > Ok, it does seem better to have a global cache from that standpoint.
> > Still, a new syscall for this doesn't seem very elegant. I also worry a
> > bit about writeback here too (like David and Neil have pointed out).
> > 
> > What about changing how we hold references on these objects instead?
> > 
> > After we look up an auth token in e.g. rpcauth_lookupcred, take a
> > reference to it and stash a pointer to it somewhere in the cred.
> > Possibly in the thread or process keyrings, but it may work better
> > elsewhere.
> > 
> > When we go to look up creds from that thread in the future, we can get
> > to it directly (which is a nice bonus). When the cred is destroyed
> > (usually on process destruction), we'd drop the reference to the object,
> > which would drop the reference to the global cache object.
> > 
> > The global cache could then be changed to have a pretty short timeout (a
> > few seconds?) and reap the object soon afterward when there are no more
> > active processes that have used it.
> 
> Wouldn’t that produce a lot of unnecessary context re-establishments. 
> 

I wouldn't think so.

As long as there is an outstanding struct cred that holds a reference to
the rpc cred, then the context will stick around and you shouldn't need
to upcall. Even if all you have is short-lived tasks, you still will
only need to upcall at the rate of the cache timeout, at the max.

Granted, timing out caches like this is a bit of a black art, and I'm
assuming that a small delay (<1 minute) between struct cred destruction
and the context destruction would be ok.

> > It's a bit more work and we might need to grow struct cred to handle it
> > (maybe give it its own keyring?), but it seems like that might be a
> > cleaner solution than giving userland knobs to manage the kernel's
> > caches.
> 
> Userland is the only place that know that kdestroy ran and is the best
> place to tell the kernel to remove its cache. Everything else is guessing.

This doesn't necessarily preclude destroying them manually. If you store
the key in a keyring you could still manually purge that reference with
a keyctl_unlink(). This approach would also mean you wouldn't need a new
syscall as well.

Regardless...I think there is a lot of mileage to be gained out of
handling cache timeouts intelligently. If for no other reason than to
have sane context timeouts for environments that can't or won't call
destroy the creds when the cache is destroyed.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
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