Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Mon, Mar 11, 2013 at 11:18:15AM -0700, Andy Lutomirski wrote: > On Tue, Mar 5, 2013 at 11:07 AM, Simo wrote: > > On 03/05/2013 01:13 PM, J. Bruce Fields wrote: > >> > >> On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: > >>> > >>> On 03/04/2013 04:19 PM, J. Bruce Fields wrote: > > On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: > > > > [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. > > I'm a little more worried: these are mandatory locks, and applications > that use them are used to the locks being enforced correctly. Are we > sure that an application that opens a file O_DENYWRITE won't crash if it > sees the file data change while it holds the open? > >>> > >>> The redirector may simply assume it has full control of that part of > >>> the file and not read nor send data until the lock is released too, > >>> so you get conflicting views of the file contents between different > >>> clients if you let a mandatory lock not be mandatory. > >>> > In general the idea of making a mandatory lock opt-in makes me nervous. > I'd prefer something like a mount option, so that we know that everyone > on that one filesystem is playing by the same rules, but we can still > mount filesystems like / without the option. > >>> > >>> +1 > >>> > But I'll admit I'm definitely not an expert on Windows locking and may > be missing something about how these locks are meant to work. > >>> > >>> Mandatory locks really are mandatory in Windows. > >>> That may not be nice to a Unix system but what can you do ? > >> > >> I wonder if we could repurpose the existing -omand mount option? > >> > >> That would be a problem for anyone that wants to allow mandatory fcntl > >> locks without allowing share locks. I doubt anyone sane actually uses > >> mandatory fcntl locks, but still I suppose it would probably be better > >> to play it safe and use a new mount option. > > > > > > Maybe we should have a -o win_semantics option :-) > > > > It's not entirely obvious to me that allowing programs to bypass this > kind of locking is a bad idea. It's hard to do on Windows, but > presumably network filesystems on Windows already have this issue. Could be, but I'd like to see evidence of that. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Tue, Mar 5, 2013 at 11:07 AM, Simo wrote: > On 03/05/2013 01:13 PM, J. Bruce Fields wrote: >> >> On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: >>> >>> On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: > > [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? >>> >>> The redirector may simply assume it has full control of that part of >>> the file and not read nor send data until the lock is released too, >>> so you get conflicting views of the file contents between different >>> clients if you let a mandatory lock not be mandatory. >>> In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. >>> >>> +1 >>> But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. >>> >>> Mandatory locks really are mandatory in Windows. >>> That may not be nice to a Unix system but what can you do ? >> >> I wonder if we could repurpose the existing -omand mount option? >> >> That would be a problem for anyone that wants to allow mandatory fcntl >> locks without allowing share locks. I doubt anyone sane actually uses >> mandatory fcntl locks, but still I suppose it would probably be better >> to play it safe and use a new mount option. > > > Maybe we should have a -o win_semantics option :-) > It's not entirely obvious to me that allowing programs to bypass this kind of locking is a bad idea. It's hard to do on Windows, but presumably network filesystems on Windows already have this issue. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
2013/3/5 Simo : > On 03/05/2013 01:13 PM, J. Bruce Fields wrote: >> >> On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: >>> >>> On 03/04/2013 04:19 PM, J. Bruce Fields wrote: I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? >>> >>> The redirector may simply assume it has full control of that part of >>> the file and not read nor send data until the lock is released too, >>> so you get conflicting views of the file contents between different >>> clients if you let a mandatory lock not be mandatory. >>> In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. >>> >>> +1 >>> But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. >>> >>> Mandatory locks really are mandatory in Windows. >>> That may not be nice to a Unix system but what can you do ? >> >> I wonder if we could repurpose the existing -omand mount option? >> >> That would be a problem for anyone that wants to allow mandatory fcntl >> locks without allowing share locks. I doubt anyone sane actually uses >> mandatory fcntl locks, but still I suppose it would probably be better >> to play it safe and use a new mount option. > > > Maybe we should have a -o win_semantics option :-) > > /me runs > (CC'ing Al Viro, since these patches should go through his tree) I don't mind to introduce a new mount option for turning this feature on/off - something like '-o denylock' to make it mathing names of new flags would be ok. Al, what do you think about this feature overall? -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
2013/3/5 Simo s...@samba.org: On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) /me runs (CC'ing Al Viro, since these patches should go through his tree) I don't mind to introduce a new mount option for turning this feature on/off - something like '-o denylock' to make it mathing names of new flags would be ok. Al, what do you think about this feature overall? -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Tue, Mar 5, 2013 at 11:07 AM, Simo s...@samba.org wrote: On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) It's not entirely obvious to me that allowing programs to bypass this kind of locking is a bad idea. It's hard to do on Windows, but presumably network filesystems on Windows already have this issue. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Mon, Mar 11, 2013 at 11:18:15AM -0700, Andy Lutomirski wrote: On Tue, Mar 5, 2013 at 11:07 AM, Simo s...@samba.org wrote: On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) It's not entirely obvious to me that allowing programs to bypass this kind of locking is a bad idea. It's hard to do on Windows, but presumably network filesystems on Windows already have this issue. Could be, but I'd like to see evidence of that. --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) /me runs Simo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: > On 03/04/2013 04:19 PM, J. Bruce Fields wrote: > >On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: > >>[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. > >I'm a little more worried: these are mandatory locks, and applications > >that use them are used to the locks being enforced correctly. Are we > >sure that an application that opens a file O_DENYWRITE won't crash if it > >sees the file data change while it holds the open? > > The redirector may simply assume it has full control of that part of > the file and not read nor send data until the lock is released too, > so you get conflicting views of the file contents between different > clients if you let a mandatory lock not be mandatory. > > >In general the idea of making a mandatory lock opt-in makes me nervous. > >I'd prefer something like a mount option, so that we know that everyone > >on that one filesystem is playing by the same rules, but we can still > >mount filesystems like / without the option. > > +1 > > >But I'll admit I'm definitely not an expert on Windows locking and may > >be missing something about how these locks are meant to work. > > Mandatory locks really are mandatory in Windows. > That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On 03/05/2013 01:13 PM, J. Bruce Fields wrote: On Mon, Mar 04, 2013 at 05:49:46PM -0500, Simo wrote: On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? I wonder if we could repurpose the existing -omand mount option? That would be a problem for anyone that wants to allow mandatory fcntl locks without allowing share locks. I doubt anyone sane actually uses mandatory fcntl locks, but still I suppose it would probably be better to play it safe and use a new mount option. Maybe we should have a -o win_semantics option :-) /me runs Simo. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? Simo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: > [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. --b. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On 03/04/2013 04:19 PM, J. Bruce Fields wrote: On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: [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. I'm a little more worried: these are mandatory locks, and applications that use them are used to the locks being enforced correctly. Are we sure that an application that opens a file O_DENYWRITE won't crash if it sees the file data change while it holds the open? The redirector may simply assume it has full control of that part of the file and not read nor send data until the lock is released too, so you get conflicting views of the file contents between different clients if you let a mandatory lock not be mandatory. In general the idea of making a mandatory lock opt-in makes me nervous. I'd prefer something like a mount option, so that we know that everyone on that one filesystem is playing by the same rules, but we can still mount filesystems like / without the option. +1 But I'll admit I'm definitely not an expert on Windows locking and may be missing something about how these locks are meant to work. Mandatory locks really are mandatory in Windows. That may not be nice to a Unix system but what can you do ? Simo. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: > > O_DENYMAND - to switch on/off three flags above. > > O_DENYMAND doesn't deny anything. Would a name like O_RESPECT_DENY be > better? Possibly rename to O_CHECK_DENY ? David -- David Laight: da...@l8s.co.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
On Thu, Feb 28, 2013 at 01:53:25PM -0800, Andy Lutomirski wrote: O_DENYMAND - to switch on/off three flags above. O_DENYMAND doesn't deny anything. Would a name like O_RESPECT_DENY be better? Possibly rename to O_CHECK_DENY ? David -- David Laight: da...@l8s.co.uk -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
2013/3/1 Andy Lutomirski : > [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. I don't mind to rename it. Your suggestion looks ok to me, thanks. -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
[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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
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. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. 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=0596193832ace26a1dd54160c7380d071a83115b The future part of open man page patch: - 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. 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. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND -> LOCK_MAND 2) !O_DENYREAD -> LOCK_READ 3) !O_DENYWRITE -> LOCK_WRITE - Pavel Shilovsky (7): 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| 6 +- 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 | 117 +++ fs/namei.c | 44 ++- 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, 345 insertions(+), 101 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe
[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
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. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. 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=0596193832ace26a1dd54160c7380d071a83115b The future part of open man page patch: - 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. 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. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND - LOCK_MAND 2) !O_DENYREAD - LOCK_READ 3) !O_DENYWRITE - LOCK_WRITE - Pavel Shilovsky (7): 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| 6 +- 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 | 117 +++ fs/namei.c | 44 ++- 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, 345 insertions(+), 101 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
[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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS
2013/3/1 Andy Lutomirski l...@amacapital.net: [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. I don't mind to rename it. Your suggestion looks ok to me, thanks. -- Best regards, Pavel Shilovsky. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
