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? _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@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
