linux-kernel - Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

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]

Message-ID: <20121207160949.GJ17115@fieldses.org>
Date:	Fri, 7 Dec 2012 11:09:49 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	simo <idra@...ba.org>
Cc:	Pavel Shilovsky <piastry@...rsoft.ru>, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	wine-devel@...ehq.org, linux-nfs@...r.kernel.org
Subject: Re: [PATCH 0/3] Add O_DENY* flags to fcntl and cifs

On Fri, Dec 07, 2012 at 10:37:45AM -0500, simo wrote:
> On Fri, 2012-12-07 at 09:52 -0500, J. Bruce Fields wrote:
> > On Fri, Dec 07, 2012 at 01:08:46PM +0400, Pavel Shilovsky wrote:
> > > 2012/12/6 Pavel Shilovsky <piastry@...rsoft.ru>:
> > > > Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules. While this change is ok for network filesystems, itsn't not targeted for local filesystems due security problems (e.g. when a user process can deny root to delete a file).
> > > >
> > > > Share flags are used by Windows applications and WINE have to deal with them too. While WINE can process open share flags itself on local filesystems, it can't do it if a file stored on a network share and is used by several clients. This patchset makes it possible for CIFS/SMB2.0/SMB3.0.
> > > >
> > > > Pavel Shilovsky (3):
> > > >   fcntl: Introduce new O_DENY* open flags for network filesystems
> > > >   CIFS: Add O_DENY* open flags support
> > > >   CIFS: Use NT_CREATE_ANDX command for forcemand mounts
> > > >
> > > >  fs/cifs/cifsacl.c                |   10 ++++----
> > > >  fs/cifs/cifsglob.h               |   11 ++++++++-
> > > >  fs/cifs/cifsproto.h              |    9 ++++----
> > > >  fs/cifs/cifssmb.c                |   47 ++++++++++++++++++++------------------
> > > >  fs/cifs/dir.c                    |   14 ++++++++----
> > > >  fs/cifs/file.c                   |   18 ++++++++++-----
> > > >  fs/cifs/inode.c                  |   11 +++++----
> > > >  fs/cifs/link.c                   |   10 ++++----
> > > >  fs/cifs/readdir.c                |    2 +-
> > > >  fs/cifs/smb1ops.c                |   15 ++++++------
> > > >  fs/cifs/smb2file.c               |   10 ++++----
> > > >  fs/cifs/smb2inode.c              |    4 ++--
> > > >  fs/cifs/smb2ops.c                |   10 ++++----
> > > >  fs/cifs/smb2pdu.c                |    6 ++---
> > > >  fs/cifs/smb2proto.h              |   14 +++++++-----
> > > >  fs/fcntl.c                       |    5 ++--
> > > >  include/uapi/asm-generic/fcntl.h |   11 +++++++++
> > > >  17 files changed, 125 insertions(+), 82 deletions(-)
> > > >
> > > > --
> > > > 1.7.10.4
> > > >
> > > 
> > > First of all, sorry for being unclear at this proposal.
> > > 
> > > 
> > > I am not from Wine team but I am working on things related to
> > > Wine+CIFS-client+Samba.
> > > 
> > > We (at Etersoft) need to organize the work of Wine applications
> > > through cifs-client share mounted to Samba (or Windows server). They
> > > are related to accounting (mostly Russian ones - e.g.
> > > http://www.1c.ru/eng/title.htm). So, the problem is that such
> > > applications use share flags to control the parallel access to the
> > > same files of several clients on a remote share. Also, there can be a
> > > situation where Windows (native) clients and Wine clients are working
> > > together in the same time.
> > > 
> > > That's why we need such flags in the kernel (patch #1). With these
> > > flags Wine can pass them to every open and they will be used by CIFS
> > > (and probably NFS) file systems to pass to the Samba server. In the
> > > same time if the file is on local filesystem - these flags will be
> > > simply ignored (not implemented).
> > 
> > NFS supports the deny-read and deny-write bits but not deny-delete.
> > 
> > If we could do such opens in-kernel on local and clustered filesystems,
> > that could also be useful for multi-protocol (Samba and NFS) and
> > clustered exports.
> > 
> > Currently knfsd tries to enforce deny bits in the nfsd code, which is a
> > bit ugly.
> > 
> > And knfsd currently requires write permissions for deny-read.  My
> > understanding is that Windows considers that wrong, but I'd be curious
> > to know whether that breaks Windows applications in practice.
> 
> It probably does if you look hard enough.
> IIRC Deny-reads are very loosely like read locks, and you can take read
> locks if you have read-only access.

I had the impression they didn't care about read or write permissions at
all, but I don't know.

> Why does knfsd restrict deny-read to read-write access ?

Because I think it's normal to want files that everyone's able to read
without giving everyone the right to DOS readers indefinitely.

And because I'm having a hard time thinking why you'd care to keep
everyone from reading a file that you don't intend to modify.

--b.
--
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/