2012/12/6 Pavel Shilovsky <piastry@xxxxxxxxxxx>: > 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). > > Share flags are used by Windows applications and WINE have to deal with them too. While WINE can process open share flags itself on local filesystems, it can't do it if a file stored on a network share and is used by several clients. This patchset makes it possible for CIFS/SMB2.0/SMB3.0. > > Pavel Shilovsky (3): > fcntl: Introduce new O_DENY* open flags for network filesystems > CIFS: Add O_DENY* open flags support > CIFS: Use NT_CREATE_ANDX command for forcemand mounts > > fs/cifs/cifsacl.c | 10 ++++---- > fs/cifs/cifsglob.h | 11 ++++++++- > fs/cifs/cifsproto.h | 9 ++++---- > fs/cifs/cifssmb.c | 47 ++++++++++++++++++++------------------ > fs/cifs/dir.c | 14 ++++++++---- > fs/cifs/file.c | 18 ++++++++++----- > fs/cifs/inode.c | 11 +++++---- > fs/cifs/link.c | 10 ++++---- > fs/cifs/readdir.c | 2 +- > fs/cifs/smb1ops.c | 15 ++++++------ > fs/cifs/smb2file.c | 10 ++++---- > fs/cifs/smb2inode.c | 4 ++-- > fs/cifs/smb2ops.c | 10 ++++---- > fs/cifs/smb2pdu.c | 6 ++--- > fs/cifs/smb2proto.h | 14 +++++++----- > fs/fcntl.c | 5 ++-- > include/uapi/asm-generic/fcntl.h | 11 +++++++++ > 17 files changed, 125 insertions(+), 82 deletions(-) > > -- > 1.7.10.4 > First of all, sorry for being unclear at this proposal. I am not from Wine team but I am working on things related to Wine+CIFS-client+Samba. We (at Etersoft) need to organize the work of Wine applications through cifs-client share mounted to Samba (or Windows server). They are related to accounting (mostly Russian ones - e.g. http://www.1c.ru/eng/title.htm). So, the problem is that such applications use share flags to control the parallel access to the same files of several clients on a remote share. Also, there can be a situation where Windows (native) clients and Wine clients are working together in the same time. That's why we need such flags in the kernel (patch #1). With these flags Wine can pass them to every open and they will be used by CIFS (and probably NFS) file systems to pass to the Samba server. In the same time if the file is on local filesystem - these flags will be simply ignored (not implemented). Now we have to make our own builds of cifs module for every kernel that use these flags passed by our build of Wine - this scheme is working but requires merging every time new kernel is released. Getting things into mainline let Wine supports more applications. As for the security layer, I don't think that we need any extra bits to switch these flags on or off - it will be switched on/off by an underlying filesystem. Since, this change is targeted for a network purpose only, a tool, that shows us what process/user locks a file, doesn't help a lot because the file can be locked remotely. As was said above, this change let us give Wine application share flags possibility for both Samba and Windows servers. Patch #2 enables share flags support for cifs mounts of Windows servers or Samba servers with nounix mount option. But we already have forcemand mount option in cifs module that switches on mandatory byte-range locking semantic for Samba without nounix. Since share flags capability is a kind of 'mandatory' locking scheme, I suggest that this option should switch on share flags for Samba without nounix too (by using NTCreateAndX command for open rather than transaction2) - that is what patch #3 does. -- Best regards, Pavel Shilovsky. -- 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
