https://bugzilla.kernel.org/show_bug.cgi?id=120671 Michael Kerrisk <mtk.manpages@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #6 from Michael Kerrisk <mtk.manpages@xxxxxxxxx> --- (In reply to Michał Zegan from comment #5) > yes, what I mean is just to make soe things more detailed in case someone > wonders. Fair enough. See the new text below, which I've added to the man page. > About filesystes, you can try to test mounting an ext4 filesystem after > doing unshare of both userns and mountns, almost sure you will fail. I mean > mounting the fs from inside of the ns. I may test that too when I have time, > to be sure, but I am almost certain that is the case, especially that > mounting an arbitrary fs could be a security risk because uids are not > shifted. When you've tested to see check that there's an issue, please reopen this bug if needed. For now, I consider the problem to be addressed, as per the new text below, so I'll close. Cheers, Michael Having a capability inside a user namespace permits a process to perform operations (that require privilege) only on resources governed by that namespace. In other words, having a capability in a user namespace permits a process to perform privileged operations on resources that are governed by (nonuser) namespaces associated with the user namespace (see the next subsection). On the other hand, there are many privi‐ leged operations that affect resources that are not associated with any namespace type, for example, changing the system time (governed by CAP_SYS_TIME), loading a kernel module (governed by CAP_SYS_MODULE), and creating a device (governed by CAP_MKNOD). Only a process with privileges in the initial user namespace can perform such operations. -- You are receiving this mail because: You are watching the assignee of the bug.-- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
