From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrey Vagin <avagin@openvz.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"W. Trevor King" <wking@tremily.us>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v3 2/2] nsfs: Add an ioctl() to return owner UID of a userns
Date: Wed, 25 Jan 2017 11:35:15 +1300 [thread overview]
Message-ID: <87sho8gk7w.fsf@xmission.com> (raw)
In-Reply-To: <daac6f7d-bc1e-bd61-355b-e47cf93e2535@gmail.com> (Michael Kerrisk's message of "Tue, 17 Jan 2017 14:03:29 +1300")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> I'd like to write code that discovers the user namespace hierarchy on
> a running system, and also shows who owns the various user namespaces.
> Currently, there is no way of getting the owner UID of a user
> namespace. Therefore, this patch adds an NS_GET_CREATOR_UID ioctl()
> that fetches the (munged) UID of the creator of the user namespace
> referred to by the specified file descriptor.
>
> If the supplied file descriptor does not refer to a user namespace,
> the operation fails with the error EINVAL.
>
> Acked-by: Andrey Vagin <avagin@openvz.org>
> Signed-off-by: Michael Kerrisk <mtk-manpages@gmail.com>
>
> ---
> Open questions:
>
> Should the type for the ioctl() argument be changed? I mean,
> make the following changes to the patch below:
>
> - unsigned int __user *argp;
> + uid_t __user *argp;
>
> And further below, change:
>
> - argp = (unsigned int __user *) arg;
> + argp = (uid_t __user *) arg;
>
> ?
>
> V3 changes:
> * Fixed data type of local variable 'uid'; thanks to Andrei Vagin
>
> V2 changes:
> * Renamed ioctl() from NS_CREATOR_UID to NS_OWNER_UID, at the
> suggestion of Eric Biederman.
> * Make ioctl() return UID via buffer pointed to by argp. (Returning
> the UID via the result value could lead to problems since a large
> unsigned int UID might be misinterpreted as an error.) Thanks to
> Andrei Vagin for pointing this out.
> ---
> fs/nsfs.c | 11 +++++++++++
> include/uapi/linux/nsfs.h | 8 +++++---
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/fs/nsfs.c b/fs/nsfs.c
> index 5d53476..63a4ad4 100644
> --- a/fs/nsfs.c
> +++ b/fs/nsfs.c
> @@ -7,6 +7,7 @@
> #include <linux/seq_file.h>
> #include <linux/user_namespace.h>
> #include <linux/nsfs.h>
> +#include <linux/uaccess.h>
>
> static struct vfsmount *nsfs_mnt;
>
> @@ -163,7 +164,10 @@ int open_related_ns(struct ns_common *ns,
> static long ns_ioctl(struct file *filp, unsigned int ioctl,
> unsigned long arg)
> {
> + struct user_namespace *user_ns;
> struct ns_common *ns = get_proc_ns(file_inode(filp));
> + unsigned int __user *argp;
> + uid_t uid;
>
> switch (ioctl) {
> case NS_GET_USERNS:
> @@ -174,6 +178,13 @@ static long ns_ioctl(struct file *filp, unsigned int ioctl,
> return open_related_ns(ns, ns->ops->get_parent);
> case NS_GET_NSTYPE:
> return ns->ops->type;
> + case NS_GET_OWNER_UID:
> + if (ns->ops->type != CLONE_NEWUSER)
> + return -EINVAL;
> + user_ns = container_of(ns, struct user_namespace, ns);
> + argp = (unsigned int __user *) arg;
> + uid = from_kuid_munged(current_user_ns(), user_ns->owner);
> + return put_user(uid, argp);
There is a question of how do we want to handle a uid that does not map.
For most interfaces that return uids the uid is one small part of
it so it is better if return the unmapped uid value.
Does this applie to NS_GET_OWNER_UID or do we perhaps want to do:
user_ns = container_of(ns, struct user_namespace, ns);
argp = (unsigned int __user *) arg;
uid = from_kuid(current_user_ns(), user_ns->owner);
if (uid == (uid_t)-1)
return -EOVERFLOW;
return put_user(uid, argp);
Which of these variants would make handling this error easiest in your
introspection code?
I suspect return -EOVERFLOW would be easiest to handle.
Eric
> default:
> return -ENOTTY;
> }
> diff --git a/include/uapi/linux/nsfs.h b/include/uapi/linux/nsfs.h
> index 2b48df1..c4a925e 100644
> --- a/include/uapi/linux/nsfs.h
> +++ b/include/uapi/linux/nsfs.h
> @@ -6,11 +6,13 @@
> #define NSIO 0xb7
>
> /* Returns a file descriptor that refers to an owning user namespace */
> -#define NS_GET_USERNS _IO(NSIO, 0x1)
> +#define NS_GET_USERNS _IO(NSIO, 0x1)
> /* Returns a file descriptor that refers to a parent namespace */
> -#define NS_GET_PARENT _IO(NSIO, 0x2)
> +#define NS_GET_PARENT _IO(NSIO, 0x2)
> /* Returns the type of namespace (CLONE_NEW* value) referred to by
> file descriptor */
> -#define NS_GET_NSTYPE _IO(NSIO, 0x3)
> +#define NS_GET_NSTYPE _IO(NSIO, 0x3)
> +/* Get owner UID for a user namespace */
> +#define NS_GET_OWNER_UID _IO(NSIO, 0x4)
>
> #endif /* __LINUX_NSFS_H */
prev parent reply other threads:[~2017-01-24 22:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <69550fe9-5347-309c-b421-79c16a6300f6@gmail.com>
2017-01-17 1:03 ` [PATCH v3 1/2] nsfs: Add an ioctl() to return the namespace type Michael Kerrisk (man-pages)
2017-01-17 1:03 ` [PATCH v3 2/2] nsfs: Add an ioctl() to return owner UID of a userns Michael Kerrisk (man-pages)
2017-01-17 1:19 ` W. Trevor King
2017-01-19 2:12 ` Michael Kerrisk (man-pages)
2017-01-24 22:35 ` Eric W. Biederman [this message]
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=87sho8gk7w.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=avagin@openvz.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
--cc=wking@tremily.us \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®