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

[Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>]

On Tue 05-07-16 09:55:18, Eric W. Biederman wrote:
> 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.

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 <jack-IBi9RG/b67k@public.gmane.org>
SUSE Labs, CR