[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
From:       Andy Lutomirski <luto () amacapital ! net>
Date:       2013-02-28 21:53:25
Message-ID: 512FD1D5.3010106 () mit ! edu
[Download RAW message or body]

[possible resend -- sorry]

On 02/28/2013 07:25 AM, 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. 
> 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.

O_DENYMAND doesn't deny anything.  Would a name like O_RESPECT_DENY be
better?

Other than that, this seems like a sensible mechanism.

--Andy


[prev in list] [next in list] [prev in thread] [next in thread]