| Message ID | 876118ruiu.fsf@x220.int.ebiederm.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 11, 2015 at 05:22:33PM -0600, Eric W. Biederman wrote: > Jeff Layton <jeff.layton@primarydata.com> writes: > > > On Wed, 11 Nov 2015 15:26:07 -0500 > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > >> On Wed, Nov 11, 2015 at 11:49:20AM -0600, Eric W. Biederman wrote: > >> > > >> > Mandatory locking appears to be almost unused and buggy and there > >> > appears no real interest in doing anything with it. Since effectively > >> > no one uses the code and since the code is buggy let's allow it to be > >> > disabled at compile time. I would just suggest removing the code but > >> > undoubtedly that will break some piece of userspace code somewhere. > >> > > >> > For the distributions that don't care about this piece of code > >> > this gives a nice starting point to make mandatory locking go away. > >> > > >> > Cc: Benjamin Coddington <bcodding@redhat.com> > >> > Cc: Dmitry Vyukov <dvyukov@google.com> > >> > Cc: Jeff Layton <jeff.layton@primarydata.com> > >> > Cc: J. Bruce Fields <bfields@fieldses.org> > >> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > >> > --- > >> > > >> > A piece of userspace software having problematic interactions with > >> > mandatory locking recently came up as an issue > >> > >> Is there any more interesting story there? > > Only that I overlooked them when implementing user namespace support for > mounting filesystems so it is currently possible to without privilege to > mount tmpfs with mandatory locking enabled and pass a file descriptor to > a daemon that was not expecting them. Causing nice denial of service > attacks. > > So I need to decide what to do with mandatory locking in user > namespaces. > > As the consensus of this thread is that users of mandatory locking are > as rare as hen's teeth I can just not allow mandatory locking if you > something is being mounted just user namespace permissions. Sounds like a plan. If nobody notices this limitation then that's further evidence that we might be able to get away with deprecating it eventually. (Well, I wouldn't be surprised if there's some test suite somewhere that includes a simple test for mandatory lock enforcement. So, any user other than that....) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 11 Nov 2015 20:33:11 -0500 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Wed, Nov 11, 2015 at 05:22:33PM -0600, Eric W. Biederman wrote: > > Jeff Layton <jeff.layton@primarydata.com> writes: > > > > > On Wed, 11 Nov 2015 15:26:07 -0500 > > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > > > >> On Wed, Nov 11, 2015 at 11:49:20AM -0600, Eric W. Biederman wrote: > > >> > > > >> > Mandatory locking appears to be almost unused and buggy and there > > >> > appears no real interest in doing anything with it. Since effectively > > >> > no one uses the code and since the code is buggy let's allow it to be > > >> > disabled at compile time. I would just suggest removing the code but > > >> > undoubtedly that will break some piece of userspace code somewhere. > > >> > > > >> > For the distributions that don't care about this piece of code > > >> > this gives a nice starting point to make mandatory locking go away. > > >> > > > >> > Cc: Benjamin Coddington <bcodding@redhat.com> > > >> > Cc: Dmitry Vyukov <dvyukov@google.com> > > >> > Cc: Jeff Layton <jeff.layton@primarydata.com> > > >> > Cc: J. Bruce Fields <bfields@fieldses.org> > > >> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > >> > --- > > >> > > > >> > A piece of userspace software having problematic interactions with > > >> > mandatory locking recently came up as an issue > > >> > > >> Is there any more interesting story there? > > > > Only that I overlooked them when implementing user namespace support for > > mounting filesystems so it is currently possible to without privilege to > > mount tmpfs with mandatory locking enabled and pass a file descriptor to > > a daemon that was not expecting them. Causing nice denial of service > > attacks. > > > > So I need to decide what to do with mandatory locking in user > > namespaces. > > > > As the consensus of this thread is that users of mandatory locking are > > as rare as hen's teeth I can just not allow mandatory locking if you > > something is being mounted just user namespace permissions. > > Sounds like a plan. If nobody notices this limitation then that's > further evidence that we might be able to get away with deprecating it > eventually. > > (Well, I wouldn't be surprised if there's some test suite somewhere that > includes a simple test for mandatory lock enforcement. So, any user > other than that....) > Yeah, ISTR that there are some (maybe in LTP)? Still, we have all sorts of options to disable pieces of the kernel these days for the tinification effort. This is just another. Heck, we've already had CONFIG_FILE_LOCKING forever, so allowing people to disable just mandatory locking seems harmless enough.
On Wed, 11 Nov 2015 17:22:33 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote: > Jeff Layton <jeff.layton@primarydata.com> writes: > > > On Wed, 11 Nov 2015 15:26:07 -0500 > > "J. Bruce Fields" <bfields@fieldses.org> wrote: > > > >> On Wed, Nov 11, 2015 at 11:49:20AM -0600, Eric W. Biederman wrote: > >> > > >> > Mandatory locking appears to be almost unused and buggy and there > >> > appears no real interest in doing anything with it. Since effectively > >> > no one uses the code and since the code is buggy let's allow it to be > >> > disabled at compile time. I would just suggest removing the code but > >> > undoubtedly that will break some piece of userspace code somewhere. > >> > > >> > For the distributions that don't care about this piece of code > >> > this gives a nice starting point to make mandatory locking go away. > >> > > >> > Cc: Benjamin Coddington <bcodding@redhat.com> > >> > Cc: Dmitry Vyukov <dvyukov@google.com> > >> > Cc: Jeff Layton <jeff.layton@primarydata.com> > >> > Cc: J. Bruce Fields <bfields@fieldses.org> > >> > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > >> > --- > >> > > >> > A piece of userspace software having problematic interactions with > >> > mandatory locking recently came up as an issue > >> > >> Is there any more interesting story there? > > Only that I overlooked them when implementing user namespace support for > mounting filesystems so it is currently possible to without privilege to > mount tmpfs with mandatory locking enabled and pass a file descriptor to > a daemon that was not expecting them. Causing nice denial of service > attacks. > > So I need to decide what to do with mandatory locking in user > namespaces. > > As the consensus of this thread is that users of mandatory locking are > as rare as hen's teeth I can just not allow mandatory locking if you > something is being mounted just user namespace permissions. If users > would be more wide spread I would need to figure out how to avoid breaking > users. > > >> > and I am wondering if there are enough people actually using and > >> > interested in mandatory locking that it makes sense to push people to > >> > support it, or if mandatory locking should be confined to it's own > >> > little corner of existence where it can wither and die. > >> > >> I hate mandatory locking and would be delighted, but my opinion probably > >> shouldn't get too much weight. > >> > > > > Ditto...It's really hard to believe that anyone uses them, given the > > well documented races in the Linux implementation. > > >> > From what little I can glean we want to discourage people from using > >> > mandatory locking and to let it wither and die. A Kconfig option that > >> > allows mandatory locking to be disabled at compile time seems like the > >> > first step in making that happen. Perhaps in a decade or so when all > >> > linux distributions are setting the option we can remove the code. > >> > > >> > Does anyone know of any real world use cases of mandatory locking? > >> > >> Isn't byte-range locking on Windows mandatory? So Samba people might be > >> the ones to talk to. (Or Wine? Or anyone else doing Windows > >> interoperability.) > >> > >> My suspicion would be that the semantics they need are different enough > >> from what we support that we'd be better off ignoring it and starting > >> over from scratch anyway. But I could be wrong. > >> > > > > Windows BRLs are mandatory but they have totally different semantics. > > > > I think there is little reason to keep POSIX mandatory locks for > > windows emulation purposes. I'm pretty sure Samba doesn't rely on them, > > for instance, given that you have to use a funky mode bit combo to > > enable them. > > > > This patch seems like a logical step to me. I'll review it soon and > > will plan to queue it up for v4.5 unless there are objections between > > now and the next merge window. > > Thanks. > > 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@xmission.com> > 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@xmission.com> > --- > 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.
Jeff Layton <jeff.layton@primarydata.com> 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@xmission.com> >> 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@xmission.com> >> --- >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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); } /*