Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> writes: >> Given the general concensus of this thread it looks like we will also >> want this incremental patch to deal with the user namespace case. >> >> From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> >> Date: Wed, 11 Nov 2015 17:18:07 -0600 >> Subject: [PATCH] locks: Don't allow mounts in user namespaces to enable mandatory locking >> >> Since no one uses mandatory locking and files with mandatory locks can >> cause problems don't allow them in user namespaces. >> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> >> --- >> fs/namespace.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/namespace.c b/fs/namespace.c >> index dee44b4791f0..95a349d5003d 100644 >> --- a/fs/namespace.c >> +++ b/fs/namespace.c >> @@ -1589,7 +1589,7 @@ static inline bool may_mandlock(void) >> #ifndef CONFIG_MANDATORY_FILE_LOCKING >> return false; >> #endif >> - return true; >> + return capable(CAP_SYS_ADMIN); >> } >> >> /* > > Fair enough. I'll merge that as well and we'll see what breaks. Sounds good. If something breaks just revert this bit. The ways things work today is not an issue if people are actually using mandatory file locking. The fundamental issues that triggered my looking into this was a single threaded server that accepts input from unprivileged users and hangs if reading that input takes too long. Mandatory locking just made it easier to supply an input that hangs. There are a countless other ways to make reading lots of data from a file descriptor slow, the obvious ones being cpu load, disk load (for local filesystems), and network load (for network filesystems). Passing file descriptors appears to be the only path where mandatory locking from files in a user namespace can affect processes outside of the user namespace. Given that there are many other ways to trigger a slow file descriptor, that mandatory locking problems are easy to avoid, I just can not see the existing kernel behavior as being wrong. The current state of affairs is a problem in that we have a feature in the kernel that apparently no one uses and everyone ignores. Turning off the feature is the right solution for that. There is a privileged operation involved with enabling "-o mand" on a filesystem. The intent and the only value I can see in the "-o mand" flag is that it determines if a filesystem will interpret the a specific combinationation of file mode bits as specifying mandatory locking on a file. Allowing that on files accessible only to users inside of the user namespace will not cause problems for the rest of the system except potentially with passed file descriptors. 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
