Re: [PATCH review 07/11] vfs: Don't create inodes with a uid or gid unknown to the vfs

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org> writes:

> On Tue 05-07-16 09:55:18, Eric W. Biederman wrote:

>> To create a superblock has s_user_ns != &init_user_ns something like
>> the following has to occur.
>> 
>> setuid(1000);
>> unshare(CLONE_NEWUSER);
>> unshare(CLONE_NEWNS);
>> mount(....);
>> 
>> At which point the oridinary root user can not see the filesystem
>> with s_user_ns != &init_user_ns as it is located in another mount
>> namespace.
>> 
>> Which means root has to use setns to get into that mount namespace,
>> so there are going to be larger hints than -EOVERFLOW.
>
> OK, I see. Thanks for explanation. The inability of the admin (UID 0 in
> init_user_ns) to easily see and change any filesystem mounted in the system
> makes me somewhat nervous ;). But I guess the complexity is the price for
> the flexibility...

Certainly the price of not allowing unprivileged users to confuse
existing setuid 0 and setcap executables.

There are days I really wish I could do things the plan9 way and throw
out any legacy baggage that makes things hard to implement.  As I recall
plan9 threw out setuid, setgid and only supported the 9p filesystem to
make this all simple and almost safe.

Wonderfully and horribly I have to keep a lot more real world code
usable in this framework.

All of that said with the existence of CRIU I expect we will ultimately
have all of the interfaces needed for adminstration applications to see
everything that is going on.  Unfortunately sometimes those interfaces
and tools lag behind the rest of the work.

Eric