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 Sat 02-07-16 12:20:31, Eric W. Biederman wrote:
>> It is expected that filesystems can not represent uids and gids from
>> outside of their user namespace.  Keep things simple by not even
>> trying to create filesystem nodes with non-sense uids and gids.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>
> So if we have sb->s_user_ns that doesn't map UID and GID 0, root cannot
> directly create files in this filesystem. EOVERFLOW error will at least
> hint us where the problem is but still I'm suspecting this is going to
> create hard to debug configuration issues... I'm not sure if we can do
> anything about this but I wanted to point it out.

A reasonable point.

A couple of details.

- If there is no uid or gid 0 inside of a user namespace there is
  no root user in that namespace so this is a moot point.

- If we are talking about uid 0 in the initial user namespace the
  scenario you are worried about can occur, but you have to work at it
  to get into that situation.

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.

At the same time if there are better error codes that make it clearer
what is happening I am all ears.

Eric