Re: Support for applications which need NFS or CIFS "share_deny"flags on open

From: Jeremy Allison
Date: Tue Dec 02 2008 - 18:29:14 EST

On Tue, Dec 02, 2008 at 12:38:20PM -0700, Andreas Dilger wrote:
> On Dec 02, 2008 10:31 -0600, Steve French wrote:
> > Some of the Wine community posted last month to the cifs mailing list
> > asking about a change needed for Wine for working properly over
> > network mounts, but the change is not really cifs specific and would
> > help other file systems as well so I wanted to mention it here. The
> > original post was:
> >
> >
> > Support for the flags they suggest would be easy for cifs (the
> > protocol has a field for this, and cifs clients on various other OS
> > set it), and should be fairly easy for NFSv4 (the RFC for NFSv4
> > specifies the "share_deny" field within the NFS open request, and
> > various clients, but not Linux, set it), and would allow WINE to
> > function properly over a network mount.
> >
> > >we proffer to add into the file /usr/include/asm-generic/fcntl.h
> > > following flags:
> > >
> > >#define O_DENYREAD 004000000 /* Do not permit read access */
> > >#define O_DENYWRITE 010000000 /* Do not permit write access */
> > >#define O_DENYDELETE 020000000 /* Do not permit delete or rename
> > > operations*/
> >
> > Presumably for applications on local mounts, wine mediates their own
> > mandatory locks, but this is impossible on network mounts without this
> > change (and can lead to data corruption).
> This is a disaster waiting to happen, and I would be against adding
> such functionality to Linux. It would allow userspace applications
> to implement a denial of service to any file that they can open (e.g.
> open("/lib/", O_DENYREAD) would be really bad :-).

Indeed. If these flags are added it should only be for network
filesystem access, it would be a real mess for local access.

I guess it makes sense for them to be the inverse of the Windows
as by default Linux clients would use all these bits for a normal

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at