Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxxxx> > > 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 -- 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
