On Wed, 11 Nov 2015 20:33:11 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Nov 11, 2015 at 05:22:33PM -0600, Eric W. Biederman wrote: > > Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> writes: > > > > > On Wed, 11 Nov 2015 15:26:07 -0500 > > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> 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@xxxxxxxxxx> > > >> > Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > > >> > Cc: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> > > >> > Cc: J. Bruce Fields <bfields@xxxxxxxxxxxx> > > >> > Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > > >> > --- > > >> > > > >> > 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. -- Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> -- 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
