On Thu, Dec 06, 2012 at 07:49:49PM +0000, Alan Cox wrote: > On Thu, 6 Dec 2012 22:26:28 +0400 > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network filesystems, itsn't not targeted for local filesystems due security problems (e.g. when a user process can deny root to delete a file). > > If I have my root fs on NFS then the same applies does it not. > > Your patches fail to describe the security semantics and what file rights > I must have to apply each option. How do I track down a lock user, what > tools are provided ? How do the new options interact with the security > layer? > > I don't have a problem with the idea, but it needs a lot more clear > description of how it works so the model can be checked and if need be > things tweaked (eg needing write to denywrite etc) And this is where things get really ugly of course :-). For the CIFSFS client they're expecting to be able to just ship them to a Windows server, where they'll get the (insane) Windows semantics. These semantics are not what would be wanted on a local filesystem. So unless we just say "these things have Windows semantics" (where openers of files can lock out others under dubious circumstances) there'll be this horrible difference between (I'm assuming) the sane semantics that are defined for local filesystems and the insane ones that you get when you're connecting remotely. I don't know a good way to fix that, but I'm pretty sure you don't want the Windows semantics defined locally :-). Jeremy. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
