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

Jan Kara [off-list ref] writes:

On Sat 02-07-16 12:20:31, Eric W. Biederman wrote:

quoted

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

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

Jan Kara [off-list ref] writes:

quoted

On Sat 02-07-16 12:20:31, Eric W. Biederman wrote:

quoted

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.

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...

								Honza
-- 
Jan Kara [off-list ref]
SUSE Labs, CR