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

[Jeremy Allison]

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:
> > http://marc.info/?l=linux-cifs-client&m=122505569315992&w=2
> > 
> > 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/libc-2.7.so", 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
CreateFile call FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE
as by default Linux clients would use all these bits for a normal
open.

Jeremy.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/