From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [RFC][PATCH] locks: Allow disabling mandatory locking at compile time Date: Wed, 11 Nov 2015 20:33:11 -0500 Message-ID: <20151112013311.GA32064@fieldses.org> References: <876118v333.fsf@x220.int.ebiederm.org> <20151111202607.GD29410@fieldses.org> <20151111174401.5778153c@tlielax.poochiereds.net> <876118ruiu.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff Layton , linux-fsdevel@vger.kernel.org, Benjamin Coddington , Dmitry Vyukov , Linux Containers To: "Eric W. Biederman" Return-path: Received: from fieldses.org ([173.255.197.46]:36098 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394AbbKLBdO (ORCPT ); Wed, 11 Nov 2015 20:33:14 -0500 Content-Disposition: inline In-Reply-To: <876118ruiu.fsf@x220.int.ebiederm.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Nov 11, 2015 at 05:22:33PM -0600, Eric W. Biederman wrote: > Jeff Layton writes: > > > On Wed, 11 Nov 2015 15:26:07 -0500 > > "J. Bruce Fields" 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 > >> > Cc: Dmitry Vyukov > >> > Cc: Jeff Layton > >> > Cc: J. Bruce Fields > >> > Signed-off-by: "Eric W. Biederman" > >> > --- > >> > > >> > 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.