From: "Serge E. Hallyn" <serge@hallyn.com>
To: Miklos Szeredi <miklos@szeredi.hu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Serge Hallyn <serge.hallyn@ubuntu.com>,
fuse-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces
Date: Wed, 10 Sep 2014 18:21:55 +0200 [thread overview]
Message-ID: <20140910162155.GA7748@mail.hallyn.com> (raw)
In-Reply-To: <20140910123525.GA29064@ubuntu-hedt>
Quoting Seth Forshee (seth.forshee@canonical.com):
> On Tue, Sep 02, 2014 at 10:44:53AM -0500, Seth Forshee wrote:
> > Another issue mentioned by Eric was what to use for i_[ug]id if the ids
> > from userspace don't map into the user namespace, which is going to be a
> > problem for any other filesystems which become mountable from user
> > namespaces as well. We discussed a few options for addressing this, the
> > most promising of which seems to be either using INVALID_[UG]ID for
> > these inodes or creating vfs-wide "nobody" ids for this purpose. After
> > thinking about it for a while I'm favoring using the invalid ids, but
> > I'm hoping to solicit some more feedback.
> >
> > For now these patches are using invalid ids if the user doesn't map into
> > the namespace. I went through the vfs code and found one place where
> > this could be handled better (addressed in patch 1 of the series). The
> > only other issue I found was that currently no one, not even root, can
> > change onwership of such inodes, but I suspect we can find a way around
> > this.
>
> I started playing around with using -2 as a global nobody id. The
> changes below (made on top of this series) are working fine in light
> testing. I'm still not sure about the security implications of doing
> this though. Possibly the nobody id should be removed from init_user_ns
> to prevent any use of the id to gain unauthroized access to such files.
> Thoughts?
Can you explain the downsides of just using -1? What are we able to do
(as a fuse-in-container user) when we use -2 that we can't do when it
uses -1?
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index c0b9968db6a1..893fc0d6ff96 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -905,8 +905,8 @@ static void fuse_fillattr(struct inode *inode, struct fuse_attr *attr,
> stat->ino = attr->ino;
> stat->mode = (inode->i_mode & S_IFMT) | (attr->mode & 07777);
> stat->nlink = attr->nlink;
> - stat->uid = make_kuid(fc->user_ns, attr->uid);
> - stat->gid = make_kgid(fc->user_ns, attr->gid);
> + stat->uid = make_kuid_munged(fc->user_ns, attr->uid);
> + stat->gid = make_kgid_munged(fc->user_ns, attr->gid);
> stat->rdev = inode->i_rdev;
> stat->atime.tv_sec = attr->atime;
> stat->atime.tv_nsec = attr->atimensec;
> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
> index f3a3ded82f85..330ac3d502a6 100644
> --- a/fs/fuse/inode.c
> +++ b/fs/fuse/inode.c
> @@ -167,8 +167,8 @@ void fuse_change_attributes_common(struct inode *inode, struct fuse_attr *attr,
> inode->i_ino = fuse_squash_ino(attr->ino);
> inode->i_mode = (inode->i_mode & S_IFMT) | (attr->mode & 07777);
> set_nlink(inode, attr->nlink);
> - inode->i_uid = make_kuid(fc->user_ns, attr->uid);
> - inode->i_gid = make_kgid(fc->user_ns, attr->gid);
> + inode->i_uid = make_kuid_munged(fc->user_ns, attr->uid);
> + inode->i_gid = make_kgid_munged(fc->user_ns, attr->gid);
> inode->i_blocks = attr->blocks;
> inode->i_atime.tv_sec = attr->atime;
> inode->i_atime.tv_nsec = attr->atimensec;
> diff --git a/include/linux/uidgid.h b/include/linux/uidgid.h
> index 6c302267f7cc..9054273af163 100644
> --- a/include/linux/uidgid.h
> +++ b/include/linux/uidgid.h
> @@ -45,6 +45,9 @@ static inline gid_t __kgid_val(kgid_t gid)
> #define INVALID_UID KUIDT_INIT(-1)
> #define INVALID_GID KGIDT_INIT(-1)
>
> +#define NOBODY_UID KUIDT_INIT(-2)
> +#define NOBODY_GID KGIDT_INIT(-2)
> +
> static inline bool uid_eq(kuid_t left, kuid_t right)
> {
> return __kuid_val(left) == __kuid_val(right);
> @@ -175,4 +178,44 @@ static inline bool kgid_has_mapping(struct user_namespace *ns, kgid_t gid)
>
> #endif /* CONFIG_USER_NS */
>
> +/**
> + * make_kuid_munged - Map a user-namespace uid pair into a kuid
> + * @from: User namespace that the uid is in
> + * @uid: User identifier
> + *
> + * Maps a user-namespace uid pair into a kernel internal kuid,
> + * and returns that kuid.
> + *
> + * Unlike make_kuid, make_kuid_munged never fails and always
> + * returns a valid uid. If @uid has no mapping in @from
> + * NOBODY_UID is returned.
> + */
> +static inline kuid_t make_kuid_munged(struct user_namespace *from, uid_t uid)
> +{
> + kuid_t kuid = make_kuid(from, uid);
> + if (!uid_valid(kuid))
> + kuid = NOBODY_UID;
> + return kuid;
> +}
> +
> +/**
> + * make_kgid_munged - Map a user-namespace gid pair into a kgid
> + * @from: User namespace that the gid is in
> + * @gid: User identifier
> + *
> + * Maps a user-namespace gid pair into a kernel internal kgid,
> + * and returns that kgid.
> + *
> + * Unlike make_kgid, make_kgid_munged never fails and always
> + * returns a valid gid. If @gid has no mapping in @from
> + * NOBODY_GID is returned.
> + */
> +static inline kgid_t make_kgid_munged(struct user_namespace *from, gid_t gid)
> +{
> + kgid_t kgid = make_kgid(from, gid);
> + if (!gid_valid(kgid))
> + kgid = NOBODY_GID;
> + return kgid;
> +}
> +
> #endif /* _LINUX_UIDGID_H */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2014-09-10 16:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 15:44 [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces Seth Forshee
2014-09-02 15:44 ` [PATCH v2 1/3] vfs: Check for invalid i_uid in may_follow_link() Seth Forshee
2014-09-05 17:05 ` Serge Hallyn
2014-09-05 19:00 ` Seth Forshee
2014-09-05 19:23 ` Serge Hallyn
2014-09-02 15:44 ` [PATCH v2 2/3] fuse: Translate pids passed to userspace into pid namespaces Seth Forshee
2014-09-05 17:10 ` Serge Hallyn
2014-09-02 15:44 ` [PATCH v2 3/3] fuse: Add support for mounts from user namespaces Seth Forshee
2014-09-05 16:48 ` Serge Hallyn
2014-09-05 17:36 ` Seth Forshee
2014-09-05 19:25 ` Serge Hallyn
2014-09-05 20:40 ` [PATCH v2 0/3] fuse: Add support for mounts from pid/user namespaces Seth Forshee
2014-09-10 12:35 ` Seth Forshee
2014-09-10 16:21 ` Serge E. Hallyn [this message]
2014-09-10 16:42 ` Seth Forshee
2014-09-11 18:10 ` Seth Forshee
2014-09-23 22:29 ` Eric W. Biederman
2014-09-24 13:29 ` Seth Forshee
2014-09-24 17:10 ` Eric W. Biederman
2014-09-25 15:04 ` Miklos Szeredi
2014-09-25 16:21 ` Seth Forshee
2014-09-25 18:05 ` Eric W. Biederman
2014-09-25 18:44 ` Seth Forshee
2014-09-25 18:53 ` Seth Forshee
2014-09-25 19:14 ` Eric W. Biederman
2014-09-25 19:48 ` Seth Forshee
2014-09-27 1:41 ` Eric W. Biederman
2014-09-27 4:24 ` Seth Forshee
2014-09-29 19:34 ` Eric W. Biederman
2014-09-30 16:25 ` Seth Forshee
2014-10-05 16:48 ` Seth Forshee
2014-10-06 16:00 ` Serge Hallyn
2014-10-06 16:31 ` Seth Forshee
2014-10-06 16:36 ` Serge Hallyn
2014-09-23 16:07 ` Miklos Szeredi
2014-09-23 16:26 ` Seth Forshee
2014-09-23 17:03 ` Miklos Szeredi
2014-09-23 17:33 ` Seth Forshee
2014-09-23 21:46 ` Eric W. Biederman
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=20140910162155.GA7748@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=ebiederm@xmission.com \
--cc=fuse-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=serge.hallyn@ubuntu.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).