[PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.

These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.

According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.

So, we have four new flags:
O_DENYREAD - to prevent other opens with read access,
O_DENYWRITE - to prevent other opens with write access,
O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
O_DENYMAND - to switch on/off three flags above.

The #1 patch bring infrastructure to let us add this capability easier. #2 patch adds flags to fcntl while #3 patch implement VFS part. Patches #4, #5, #6 are related to CIFS-specific changes. #7 and #8 describe NFS and NFSD parts.

Also, I created the preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags:
http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=f116c478bf9a1bc3985e9a719fb20d854914d67a

Pavel Shilovsky (8):
  locks: make flock_lock_file take is_conflict callback parm
  fcntl: Introduce new O_DENY* open flags
  vfs: Add O_DENYREAD/WRITE flags support for open syscall
  CIFS: Add O_DENY* open flags support
  CIFS: Use NT_CREATE_ANDX command for forcemand mounts
  CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2
  NFSv4: Add O_DENY* open flags support
  NFSD: Pass share reservations flags to VFS

 fs/cifs/cifsacl.c                |  10 ++--
 fs/cifs/cifsglob.h               |  12 +++-
 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/smb2maperror.c           |   2 +-
 fs/cifs/smb2ops.c                |  10 ++--
 fs/cifs/smb2pdu.c                |   6 +-
 fs/cifs/smb2proto.h              |  14 +++--
 fs/fcntl.c                       |   5 +-
 fs/locks.c                       | 121 ++++++++++++++++++++++++++++++++++++---
 fs/namei.c                       |  10 +++-
 fs/nfs/nfs4xdr.c                 |  24 ++++++--
 fs/nfsd/nfs4state.c              |  46 ++++++++++++++-
 include/linux/fs.h               |   6 ++
 include/uapi/asm-generic/fcntl.h |  14 +++++
 23 files changed, 324 insertions(+), 96 deletions(-)

-- 
1.8.1.1

[PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.

These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.

According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.

So, we have four new flags:
O_DENYREAD - to prevent other opens with read access,
O_DENYWRITE - to prevent other opens with write access,
O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
O_DENYMAND - to switch on/off three flags above.

The #1 patch bring infrastructure to let us add this capability easier. #2 patch adds flags to fcntl while #3 patch implement VFS part. Patches #4, #5, #6 are related to CIFS-specific changes. #7 and #8 describe NFS and NFSD parts.

Also, I created the preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags:
http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=f116c478bf9a1bc3985e9a719fb20d854914d67a

Pavel Shilovsky (8):
  locks: make flock_lock_file take is_conflict callback parm
  fcntl: Introduce new O_DENY* open flags
  vfs: Add O_DENYREAD/WRITE flags support for open syscall
  CIFS: Add O_DENY* open flags support
  CIFS: Use NT_CREATE_ANDX command for forcemand mounts
  CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2
  NFSv4: Add O_DENY* open flags support
  NFSD: Pass share reservations flags to VFS

 fs/cifs/cifsacl.c                |  10 ++--
 fs/cifs/cifsglob.h               |  12 +++-
 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/smb2maperror.c           |   2 +-
 fs/cifs/smb2ops.c                |  10 ++--
 fs/cifs/smb2pdu.c                |   6 +-
 fs/cifs/smb2proto.h              |  14 +++--
 fs/fcntl.c                       |   5 +-
 fs/locks.c                       | 121 ++++++++++++++++++++++++++++++++++++---
 fs/namei.c                       |  10 +++-
 fs/nfs/nfs4xdr.c                 |  24 ++++++--
 fs/nfsd/nfs4state.c              |  46 ++++++++++++++-
 include/linux/fs.h               |   6 ++
 include/uapi/asm-generic/fcntl.h |  14 +++++
 23 files changed, 324 insertions(+), 96 deletions(-)

-- 
1.8.1.1

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

Hi Pavel,

On Thu, 17 Jan 2013 20:52:09 +0400 Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org> wrote:
>
> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.

This has probably been discussed, but is Linux's leases implementation
not sufficient?  Just wondering.

-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

Hi Pavel,

On Thu, 17 Jan 2013 20:52:09 +0400 Pavel Shilovsky <piastry@etersoft.ru> wrote:
>
> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.

This has probably been discussed, but is Linux's leases implementation
not sufficient?  Just wondering.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

2013/1/18 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi Pavel,
>
> On Thu, 17 Jan 2013 20:52:09 +0400 Pavel Shilovsky <piastry@etersoft.ru> wrote:
>>
>> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
>
> This has probably been discussed, but is Linux's leases implementation
> not sufficient?  Just wondering.

As I understand it, leases play different role: they allow to cache a
data for the particular open and then flush it when a lease break
comes. But we need to protect opens from being done if their
access/share mode is not suitable for previously done opens. E.g. if
we have already opened a file with O_RDONLY | O_DENYWRITE we can't
open it again with any of O_WRONLY, O_RDWR and O_DENYREAD flags (of
course all these things should only work if O_DENYMAND is specified
for the first and the second opens).

-- 
Best regards,
Pavel Shilovsky.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[J. Bruce Fields]

On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
> 
> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
> 
> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.

Maybe that's good enough.  A mount flag might be simpler and give
consistent enforcement for all users.

> 
> So, we have four new flags:
> O_DENYREAD - to prevent other opens with read access,
> O_DENYWRITE - to prevent other opens with write access,
> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
> O_DENYMAND - to switch on/off three flags above.

It would be useful to have some really careful documentation of how
these are meant to work.  Maybe try updating the open man page?

--b.
> 
> The #1 patch bring infrastructure to let us add this capability easier. #2 patch adds flags to fcntl while #3 patch implement VFS part. Patches #4, #5, #6 are related to CIFS-specific changes. #7 and #8 describe NFS and NFSD parts.
> 
> Also, I created the preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags:
> http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=f116c478bf9a1bc3985e9a719fb20d854914d67a
> 
> Pavel Shilovsky (8):
>   locks: make flock_lock_file take is_conflict callback parm
>   fcntl: Introduce new O_DENY* open flags
>   vfs: Add O_DENYREAD/WRITE flags support for open syscall
>   CIFS: Add O_DENY* open flags support
>   CIFS: Use NT_CREATE_ANDX command for forcemand mounts
>   CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2
>   NFSv4: Add O_DENY* open flags support
>   NFSD: Pass share reservations flags to VFS
> 
>  fs/cifs/cifsacl.c                |  10 ++--
>  fs/cifs/cifsglob.h               |  12 +++-
>  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/smb2maperror.c           |   2 +-
>  fs/cifs/smb2ops.c                |  10 ++--
>  fs/cifs/smb2pdu.c                |   6 +-
>  fs/cifs/smb2proto.h              |  14 +++--
>  fs/fcntl.c                       |   5 +-
>  fs/locks.c                       | 121 ++++++++++++++++++++++++++++++++++++---
>  fs/namei.c                       |  10 +++-
>  fs/nfs/nfs4xdr.c                 |  24 ++++++--
>  fs/nfsd/nfs4state.c              |  46 ++++++++++++++-
>  include/linux/fs.h               |   6 ++
>  include/uapi/asm-generic/fcntl.h |  14 +++++
>  23 files changed, 324 insertions(+), 96 deletions(-)
> 
> -- 
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[J. Bruce Fields]

On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
> 
> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
> 
> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.

Maybe that's good enough.  A mount flag might be simpler and give
consistent enforcement for all users.

> 
> So, we have four new flags:
> O_DENYREAD - to prevent other opens with read access,
> O_DENYWRITE - to prevent other opens with write access,
> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
> O_DENYMAND - to switch on/off three flags above.

It would be useful to have some really careful documentation of how
these are meant to work.  Maybe try updating the open man page?

--b.
> 
> The #1 patch bring infrastructure to let us add this capability easier. #2 patch adds flags to fcntl while #3 patch implement VFS part. Patches #4, #5, #6 are related to CIFS-specific changes. #7 and #8 describe NFS and NFSD parts.
> 
> Also, I created the preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags:
> http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=f116c478bf9a1bc3985e9a719fb20d854914d67a
> 
> Pavel Shilovsky (8):
>   locks: make flock_lock_file take is_conflict callback parm
>   fcntl: Introduce new O_DENY* open flags
>   vfs: Add O_DENYREAD/WRITE flags support for open syscall
>   CIFS: Add O_DENY* open flags support
>   CIFS: Use NT_CREATE_ANDX command for forcemand mounts
>   CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2
>   NFSv4: Add O_DENY* open flags support
>   NFSD: Pass share reservations flags to VFS
> 
>  fs/cifs/cifsacl.c                |  10 ++--
>  fs/cifs/cifsglob.h               |  12 +++-
>  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/smb2maperror.c           |   2 +-
>  fs/cifs/smb2ops.c                |  10 ++--
>  fs/cifs/smb2pdu.c                |   6 +-
>  fs/cifs/smb2proto.h              |  14 +++--
>  fs/fcntl.c                       |   5 +-
>  fs/locks.c                       | 121 ++++++++++++++++++++++++++++++++++++---
>  fs/namei.c                       |  10 +++-
>  fs/nfs/nfs4xdr.c                 |  24 ++++++--
>  fs/nfsd/nfs4state.c              |  46 ++++++++++++++-
>  include/linux/fs.h               |   6 ++
>  include/uapi/asm-generic/fcntl.h |  14 +++++
>  23 files changed, 324 insertions(+), 96 deletions(-)
> 
> -- 
> 1.8.1.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

2013/1/31 J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>:
> On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
>> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
>>
>> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
>>
>> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
>
> Maybe that's good enough.  A mount flag might be simpler and give
> consistent enforcement for all users.
>
>>
>> So, we have four new flags:
>> O_DENYREAD - to prevent other opens with read access,
>> O_DENYWRITE - to prevent other opens with write access,
>> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
>> O_DENYMAND - to switch on/off three flags above.
>
> It would be useful to have some really careful documentation of how
> these are meant to work.  Maybe try updating the open man page?

Yes, that's a good idea. Do you mean smth like this?

O_DENYMAND - used to inforce a mandatory share reservation scheme of
the file access. If this flag is passed,
the open fails with -ETXTBSY in following cases:

1) if O_DENYREAD flag is specified and there is another open with
O_DENYMAND flag and READ access to the file;
2) if O_DENYWRITE flag is specified and there is another open with
O_DENYMAND flag and WRITE access to the file;
3) if READ access is requested and there is another open with
O_DENYMAND and O_DENYREAD flags;
4) if WRITE access is requested and there is another open with
O_DENYMAND and O_DENYWRITE flags;

Also, if O_DENYDELETE flag is specified and the open succeded, any
further unlink operation will fail with -ETXTBSY untill this open is
closed. Now this flag is processed by CIFS filesystems only.

-- 
Best regards,
Pavel Shilovsky.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

2013/1/31 J. Bruce Fields <bfields@fieldses.org>:
> On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
>> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
>>
>> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
>>
>> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
>
> Maybe that's good enough.  A mount flag might be simpler and give
> consistent enforcement for all users.
>
>>
>> So, we have four new flags:
>> O_DENYREAD - to prevent other opens with read access,
>> O_DENYWRITE - to prevent other opens with write access,
>> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
>> O_DENYMAND - to switch on/off three flags above.
>
> It would be useful to have some really careful documentation of how
> these are meant to work.  Maybe try updating the open man page?

Yes, that's a good idea. Do you mean smth like this?

O_DENYMAND - used to inforce a mandatory share reservation scheme of
the file access. If this flag is passed,
the open fails with -ETXTBSY in following cases:

1) if O_DENYREAD flag is specified and there is another open with
O_DENYMAND flag and READ access to the file;
2) if O_DENYWRITE flag is specified and there is another open with
O_DENYMAND flag and WRITE access to the file;
3) if READ access is requested and there is another open with
O_DENYMAND and O_DENYREAD flags;
4) if WRITE access is requested and there is another open with
O_DENYMAND and O_DENYWRITE flags;

Also, if O_DENYDELETE flag is specified and the open succeded, any
further unlink operation will fail with -ETXTBSY untill this open is
closed. Now this flag is processed by CIFS filesystems only.

-- 
Best regards,
Pavel Shilovsky.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[J. Bruce Fields]

On Tue, Feb 05, 2013 at 03:33:21PM +0400, Pavel Shilovsky wrote:
> 2013/1/31 J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>:
> > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
> >> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
> >>
> >> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
> >>
> >> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
> >
> > Maybe that's good enough.  A mount flag might be simpler and give
> > consistent enforcement for all users.
> >
> >>
> >> So, we have four new flags:
> >> O_DENYREAD - to prevent other opens with read access,
> >> O_DENYWRITE - to prevent other opens with write access,
> >> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
> >> O_DENYMAND - to switch on/off three flags above.
> >
> > It would be useful to have some really careful documentation of how
> > these are meant to work.  Maybe try updating the open man page?
> 
> Yes, that's a good idea. Do you mean smth like this?
> 
> O_DENYMAND - used to inforce a mandatory share reservation scheme of
> the file access. If this flag is passed,
> the open fails with -ETXTBSY in following cases:
> 
> 1) if O_DENYREAD flag is specified and there is another open with
> O_DENYMAND flag and READ access to the file;
> 2) if O_DENYWRITE flag is specified and there is another open with
> O_DENYMAND flag and WRITE access to the file;
> 3) if READ access is requested and there is another open with
> O_DENYMAND and O_DENYREAD flags;
> 4) if WRITE access is requested and there is another open with
> O_DENYMAND and O_DENYWRITE flags;
> 
> Also, if O_DENYDELETE flag is specified and the open succeded, any
> further unlink operation will fail with -ETXTBSY untill this open is
> closed. Now this flag is processed by CIFS filesystems only.

Do you need to document interactions with flock() as well?

--b.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[J. Bruce Fields]

On Tue, Feb 05, 2013 at 03:33:21PM +0400, Pavel Shilovsky wrote:
> 2013/1/31 J. Bruce Fields <bfields@fieldses.org>:
> > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
> >> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
> >>
> >> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
> >>
> >> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
> >
> > Maybe that's good enough.  A mount flag might be simpler and give
> > consistent enforcement for all users.
> >
> >>
> >> So, we have four new flags:
> >> O_DENYREAD - to prevent other opens with read access,
> >> O_DENYWRITE - to prevent other opens with write access,
> >> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
> >> O_DENYMAND - to switch on/off three flags above.
> >
> > It would be useful to have some really careful documentation of how
> > these are meant to work.  Maybe try updating the open man page?
> 
> Yes, that's a good idea. Do you mean smth like this?
> 
> O_DENYMAND - used to inforce a mandatory share reservation scheme of
> the file access. If this flag is passed,
> the open fails with -ETXTBSY in following cases:
> 
> 1) if O_DENYREAD flag is specified and there is another open with
> O_DENYMAND flag and READ access to the file;
> 2) if O_DENYWRITE flag is specified and there is another open with
> O_DENYMAND flag and WRITE access to the file;
> 3) if READ access is requested and there is another open with
> O_DENYMAND and O_DENYREAD flags;
> 4) if WRITE access is requested and there is another open with
> O_DENYMAND and O_DENYWRITE flags;
> 
> Also, if O_DENYDELETE flag is specified and the open succeded, any
> further unlink operation will fail with -ETXTBSY untill this open is
> closed. Now this flag is processed by CIFS filesystems only.

Do you need to document interactions with flock() as well?

--b.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

2013/2/5 J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>:
> On Tue, Feb 05, 2013 at 03:33:21PM +0400, Pavel Shilovsky wrote:
>> 2013/1/31 J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>:
>> > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
>> >> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
>> >>
>> >> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
>> >>
>> >> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
>> >
>> > Maybe that's good enough.  A mount flag might be simpler and give
>> > consistent enforcement for all users.
>> >
>> >>
>> >> So, we have four new flags:
>> >> O_DENYREAD - to prevent other opens with read access,
>> >> O_DENYWRITE - to prevent other opens with write access,
>> >> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
>> >> O_DENYMAND - to switch on/off three flags above.
>> >
>> > It would be useful to have some really careful documentation of how
>> > these are meant to work.  Maybe try updating the open man page?
>>
>> Yes, that's a good idea. Do you mean smth like this?
>>
>> O_DENYMAND - used to inforce a mandatory share reservation scheme of
>> the file access. If this flag is passed,
>> the open fails with -ETXTBSY in following cases:
>>
>> 1) if O_DENYREAD flag is specified and there is another open with
>> O_DENYMAND flag and READ access to the file;
>> 2) if O_DENYWRITE flag is specified and there is another open with
>> O_DENYMAND flag and WRITE access to the file;
>> 3) if READ access is requested and there is another open with
>> O_DENYMAND and O_DENYREAD flags;
>> 4) if WRITE access is requested and there is another open with
>> O_DENYMAND and O_DENYWRITE flags;
>>
>> Also, if O_DENYDELETE flag is specified and the open succeded, any
>> further unlink operation will fail with -ETXTBSY untill this open is
>> closed. Now this flag is processed by CIFS filesystems only.
>
> Do you need to document interactions with flock() as well?

Yes, this needs to be documented, thanks. I am going to propose ver2
of this patchset (with regards to your suggestions) - will add this
part to open man page patch too.

-- 
Best regards,
Pavel Shilovsky.

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

[Pavel Shilovsky]

2013/2/5 J. Bruce Fields <bfields@fieldses.org>:
> On Tue, Feb 05, 2013 at 03:33:21PM +0400, Pavel Shilovsky wrote:
>> 2013/1/31 J. Bruce Fields <bfields@fieldses.org>:
>> > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote:
>> >> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic.
>> >>
>> >> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients.
>> >>
>> >> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way.
>> >
>> > Maybe that's good enough.  A mount flag might be simpler and give
>> > consistent enforcement for all users.
>> >
>> >>
>> >> So, we have four new flags:
>> >> O_DENYREAD - to prevent other opens with read access,
>> >> O_DENYWRITE - to prevent other opens with write access,
>> >> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module),
>> >> O_DENYMAND - to switch on/off three flags above.
>> >
>> > It would be useful to have some really careful documentation of how
>> > these are meant to work.  Maybe try updating the open man page?
>>
>> Yes, that's a good idea. Do you mean smth like this?
>>
>> O_DENYMAND - used to inforce a mandatory share reservation scheme of
>> the file access. If this flag is passed,
>> the open fails with -ETXTBSY in following cases:
>>
>> 1) if O_DENYREAD flag is specified and there is another open with
>> O_DENYMAND flag and READ access to the file;
>> 2) if O_DENYWRITE flag is specified and there is another open with
>> O_DENYMAND flag and WRITE access to the file;
>> 3) if READ access is requested and there is another open with
>> O_DENYMAND and O_DENYREAD flags;
>> 4) if WRITE access is requested and there is another open with
>> O_DENYMAND and O_DENYWRITE flags;
>>
>> Also, if O_DENYDELETE flag is specified and the open succeded, any
>> further unlink operation will fail with -ETXTBSY untill this open is
>> closed. Now this flag is processed by CIFS filesystems only.
>
> Do you need to document interactions with flock() as well?

Yes, this needs to be documented, thanks. I am going to propose ver2
of this patchset (with regards to your suggestions) - will add this
part to open man page patch too.

-- 
Best regards,
Pavel Shilovsky.