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"? --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
