linux-kernel - Re: Support for applications which need NFS or CIFS "share

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20081202230703.GB11904@jeremy-desktop>
Date:	Tue, 2 Dec 2008 15:07:03 -0800
From:	Jeremy Allison <jra@...ba.org>
To:	Andreas Dilger <adilger@....com>
Cc:	Steve French <smfrench@...il.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-cifs-client@...ts.samba.org" 
	<linux-cifs-client@...ts.samba.org>
Subject: Re: 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/