On Thu, Dec 6, 2012 at 1:57 PM, Jeremy Allison jra@samba.org 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@etersoft.ru 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.