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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Dec 2008 20:06:21 +0000
From:	Jamie Lokier <jamie@...reable.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

Andreas Dilger wrote:
> 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 :-).
> 
> It was always also a pain in the ass on Windows systems (back when I used
> them) that backing up the filesystem would fail because something (app or
> kernel) had files open in this mode and the backup tool couldn't even read
> them to do the backup.  In some cases these files were opened very early
> in boot and the only way to do a full backup was to boot from a separate
> device and run the backup.  Not my idea of fun.

It's a pain on Windows, yes.  It's necessary because you can't delete
or rename over an open file (the unix way), so for files which must be
updated without any program seeing them as temporarily corrup (.exe,
.dll, config files, pid files, etc.) to do it on Windows is
open-with-deny-read and write the new file contents.

> I can't see any reason for O_DENYREAD or O_DENYWRITE that can't be met
> with existing file locking to maintain coherency if that is really needed.

Good point!

Is there any reason why Wine cannot take an advisory lock _every_ time
it opens a file?  That would give Windows apps the behaviour they
expect, including across the network, without DOSing unix apps.

> As for O_DENYDELETE - wouldn't that be irrelevant if the WINE code keeps
> an open file reference?  The data would still be accessible until WINE
> exits, and it wouldn't be a DOS.

Windows apps do expect a file can't disappear while it's open.  This
is one way to detect if an app is running, and this particular
behaviour goes back to the oldest versions of Windows.

Inside a single WINE instance or on a single host, your suggestion
works, but what about Windows apps on different hosts over a network share?

The bit I find interesting is that other CIFS clients are said to
implement these flags.  If that means real unixes, maybe they've
worked out a sensible way to handle them?

-- Jamie
--
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/