On Tue, Mar 04, 2014 at 06:50:10PM -0500, Trond Myklebust wrote: > > On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote: > > > On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: > >> On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> > >> wrote: > >>> Good point: if I understand it right, in the mandatory locking case, > >>> before doing a read or write we first check if we'd be able to apply > >>> a classic posix lock. And that lock will always conflict with a > >>> file-private lock. > >>> > >>> I think we should just not worry about it and see if anyone > >>> complains. File-private locks are a new feature and I don't see > >>> that we're under any obligation to support the combination of > >>> file-private locks and mandatory locking. > >>> > >>> Mandatory locking is already buggy (because of the race between > >>> checking for locks and performing the IO). If we get no complaints > >>> about this file-private behavior then that's more evidence we could > >>> use to justify just ripping it out completely some day.... > > ... > >> The problem is that mandatory locking is something the administrator > >> and user enable. It isn’t entirely under the control of the > >> application… If you write a program that uses file-private locks, I > >> can trivially DOS it by manipulating the mount parameters and > >> manipulating the file's group execute and sgid bit. > > > > Or you could take a lock on the file and DOS it in the same way. > > > > Why isn't the answer "don't do that”? > > …because as a rule, it is bloody non-obvious and neither you nor Jeff had > thought of it? Agreed that it certainly violates the principal of least surprise. I just don't think that maintaining Linux's mandatory locking is worth any unnecessary effort. Nobody should be using it anyway as far as I can tell. But, fair enough, I don't feel terrifically strong about this, and it's probably not too hard to fix. --b. -- 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
