On 04/07/2012 10:10 PM, Eric W. Biederman wrote: > > This is a course correction for the user namespace, so that we can reach > an inexpensive, maintainable, and reasonably complete implementation. > > If anyone can think of a reason why the user namespace should not > evolve in the direction taken in this patchset please let me know. > > There is not an obvious maintainer for the scope of what this patchset > covers so I intend to host this tree myself and to place it in > linux-next after this round of review. > > Highlights. > - The kernel will now fail to build if you attempt to compile in > code whose permission checks have not been updated to be user > namespace safe. > > - All uids from child user namespaces are mapped into the initial user > namespace before they are processed. Removing the need to add > an additional check to see if the user namespace of the compared > uids remains the same. [...] I haven't read enough of the details to figure out how the uid mapping works (do all the child namespace uids map to the same parent uid?), so I may be missing some details here. As a bit of background, the no_new_privs mode introduced in the big seccomp patchset will add a flag that any task can set to prevent it or any of its children from gaining privileges by using execve. How should this interact with pid namespaces? As a first pass, I imagine that the main PR_SET_NO_NEW_PRIVS(1) mode will prevent setuid from working inside uid namespaces as well, but there may be interest in weaker variants that allow setuid inside namespaces. Any thoughts? --Andy -- 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
