From: Jeff Layton <jlayton@redhat.com>
To: Olga Kornievskaia <kolga@netapp.com>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-api@vger.kernel.org
Cc: David Howells <dhowells@redhat.com>
Subject: Re: [RFC 1/1] destroy_creds.2: new page documenting destroy_creds()
Date: Wed, 09 Aug 2017 08:30:48 -0400 [thread overview]
Message-ID: <1502281848.12841.2.camel@redhat.com> (raw)
In-Reply-To: <20170807212355.29127-3-kolga@netapp.com>
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>
next prev parent reply other threads:[~2017-08-09 12:30 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-07 21:23 [RFC v3 0/3] VFS/NFS support to destroy FS credentials Olga Kornievskaia
2017-08-07 21:23 ` Olga Kornievskaia
2017-08-07 21:23 ` [RFC v3 1/3] VFS adding destroy_creds call Olga Kornievskaia
2017-08-07 21:23 ` Olga Kornievskaia
2017-08-07 21:23 ` [RFC 1/1] destroy_creds.2: new page documenting destroy_creds() Olga Kornievskaia
2017-08-07 21:23 ` Olga Kornievskaia
2017-08-09 12:30 ` Jeff Layton [this message]
[not found] ` <1502281848.12841.2.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-09 15:45 ` Olga Kornievskaia
2017-08-09 15:45 ` Olga Kornievskaia
2017-08-11 7:17 ` NeilBrown
2017-08-11 7:17 ` NeilBrown
[not found] ` <87378yr2sx.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-08-11 11:18 ` Jeff Layton
2017-08-11 11:18 ` Jeff Layton
[not found] ` <1502450305.4950.4.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-11 14:05 ` Olga Kornievskaia
2017-08-11 14:05 ` Olga Kornievskaia
2017-08-11 14:05 ` Olga Kornievskaia
[not found] ` <E127503D-3DFC-4FD3-99F6-012D100C168B@netapp.com>
[not found] ` <E127503D-3DFC-4FD3-99F6-012D100C168B-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
2017-08-11 14:22 ` Jeff Layton
2017-08-11 14:22 ` Jeff Layton
[not found] ` <1502461341.4762.1.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-11 15:12 ` Trond Myklebust
2017-08-11 15:12 ` Trond Myklebust
2017-08-11 15:12 ` Trond Myklebust
[not found] ` <1502464329.5352.1.camel-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
2017-08-13 11:38 ` Jeff Layton
2017-08-13 11:38 ` Jeff Layton
[not found] ` <1502624339.4839.4.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-08-14 15:43 ` Olga Kornievskaia
2017-08-14 15:43 ` Olga Kornievskaia
2017-08-14 15:43 ` Olga Kornievskaia
[not found] ` <CB7D102A-5711-4661-928F-3689895A1A5A@netapp.com>
[not found] ` <CB7D102A-5711-4661-928F-3689895A1A5A-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
2017-08-14 15:59 ` Jeff Layton
2017-08-14 15:59 ` Jeff Layton
2017-08-11 13:37 ` Olga Kornievskaia
2017-08-11 13:37 ` Olga Kornievskaia
2017-08-11 13:37 ` Olga Kornievskaia
2017-08-11 14:09 ` Olga Kornievskaia
2017-08-11 14:09 ` Olga Kornievskaia
2017-08-11 14:09 ` Olga Kornievskaia
[not found] ` <20170807212355.29127-3-kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
2017-08-09 16:08 ` Andy Lutomirski
2017-08-09 16:08 ` Andy Lutomirski
2017-08-09 16:44 ` Olga Kornievskaia
[not found] ` <20170807212355.29127-1-kolga-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
2017-08-07 21:23 ` [RFC v3 2/3] SUNRPC mark user credentials destroyed Olga Kornievskaia
2017-08-07 21:23 ` Olga Kornievskaia
2017-08-07 21:23 ` [RFC v3 3/3] NFS define vfs destroy_creds functions Olga Kornievskaia
2017-08-07 21:23 ` Olga Kornievskaia
2017-08-09 12:55 ` [RFC v3 0/3] VFS/NFS support to destroy FS credentials David Howells
2017-08-09 12:55 ` David Howells
2017-08-10 16:52 ` Olga Kornievskaia
[not found] ` <CAN-5tyE11DaCCXdn3y+Q4V+Lyt_UgtzU+JBhwP68gxQc5_v6pQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-11 6:53 ` NeilBrown
2017-08-11 6:53 ` NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1502281848.12841.2.camel@redhat.com \
--to=jlayton@redhat.com \
--cc=dhowells@redhat.com \
--cc=kolga@netapp.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.