[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJfpegv5JmB15yHpjYxVeOYdWWkoLMftr9-e_iS93Y_7m=t4Zw@mail.gmail.com>
Date: Wed, 9 Mar 2016 15:48:22 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Seth Forshee <seth.forshee@...onical.com>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Serge Hallyn <serge.hallyn@...onical.com>,
Richard Weinberger <richard.weinberger@...il.com>,
Austin S Hemmelgarn <ahferroin7@...il.com>,
Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-bcache@...r.kernel.org, dm-devel@...hat.com,
linux-raid@...r.kernel.org, linux-mtd@...ts.infradead.org,
Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
fuse-devel <fuse-devel@...ts.sourceforge.net>,
LSM <linux-security-module@...r.kernel.org>,
selinux@...ho.nsa.gov
Subject: Re: [PATCH RESEND v2 16/18] fuse: Support fuse filesystems outside of init_user_ns
On Wed, Mar 9, 2016 at 3:18 PM, Seth Forshee <seth.forshee@...onical.com> wrote:
> On Wed, Mar 09, 2016 at 12:29:23PM +0100, Miklos Szeredi wrote:
>> On Mon, Jan 04, 2016 at 12:03:55PM -0600, Seth Forshee wrote:
>> > -static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev)
>> > +static int parse_fuse_opt(char *opt, struct fuse_mount_data *d, int is_bdev,
>> > + struct user_namespace *user_ns)
>> > {
>> > char *p;
>> > memset(d, 0, sizeof(struct fuse_mount_data));
>> > d->max_read = ~0;
>> > d->blksize = FUSE_DEFAULT_BLKSIZE;
>> > + d->user_id = make_kuid(user_ns, 0);
>> > + d->group_id = make_kgid(user_ns, 0);
>>
>> It is true that if "user_id=" or "group_id" options were omitted we used the
>> zero uid/gid values. However, this isn't actually used by anybody AFAIK, and
>> generalizing it for userns doesn't seem to make much sense.
>>
>> So I suggest we that we instead return an error if mounting from a userns AND
>> neither "allow_other" nor both "user_id" and "group_id" are specified.
>
> But those are also used for ownership of the connection files in
> fusectl. In an allow_other mount shouldn't those files by owned by
> namespace root and not global root?
Yes.
Can't we use current_cred()->uid/gid? Or fsuid/fsgid maybe?
When we have true unprivileged mounts, the user_id/group_id options
become redundant anyway and we can just use the current credentials.
Thanks,
Miklos
Powered by blists - more mailing lists