Re: [PATCH review 0/11] General unprivileged mount support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:

> On Sat, Jul 2, 2016 at 10:18 AM, Eric W. Biederman
> <ebiederm@xxxxxxxxxxxx> wrote:
>>
>> As well as in these patches the code is also available from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git for-testing
>>
>> It has been a long time in coming but recently in the userns tree the
>> superblock has been expanded with a s_user_ns field indicating the user
>> namespace that owns a superblock.
>>
>
> It would be nice if global root could mount otherwise-unsafe
> filesystems with s_user_ns set to a non-init namespace.  Do you have
> plans to allow that?

Looking at the code global root would pass the permission checks that
are present in my tree today.  At the same time I don't have a provision
for global root to specify the user namespace.

The practical limitation is that the filesystems need a little bit of
gentle massaging to handle the case when s_user_ns != &init_user_ns.
I think i_uid_read and i_uid_write already provide 90% of that.

The other limitation is that s_user_ns is defined as the owner of the
filesystem and as the default translation.  Which will mean root in
s_user_ns will be trusted to remount the filesystem.

The primary target right now is a safe unprivileged mount of fuse.


I am not opposed to extensions allowing the global root to mount
otherwise-unsafe filesystems with s_user_ns != &init_user_ns as long as
it is for cases where we can trust the underlying filesystem image and
don't mind giving root in s_user_ns all interesting permissions over the
filesystem.  I think that could be an very interesting intermediary step
in getting filesystems supported.  Still my focus is true unprivileged
mounts, there are a huge number of little details that go into getting
that right, and my poor brain can't handle looking at cases beyond that.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux