Jan Kara <jack@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
