lkml.org 
[lkml]   [2008]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Support for applications which need NFS or CIFS "share_deny" flags on open
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.


\
 
 \ /
  Last update: 2008-12-03 00:31    [W:0.052 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site