On Thu, Dec 6, 2012 at 1:57 PM, Jeremy Allison <jra@xxxxxxxxx> wrote: > 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 I suspect that WINE would have the same need to ship them to an NFS server as to a Windows server, and the NFS4 protocol specification also defines these, although I could not find the same level of detail that MS-FSA provides (e.g. see section 2.14.10 for the detailed description of how lock conflicts are checked) but the semantics are probably the same. -- Thanks, Steve -- 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
