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]

Date:	Thu, 6 Dec 2012 11:57:52 -0800
From:	Jeremy Allison <jra@...ba.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
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 Thu, Dec 06, 2012 at 07:49:49PM +0000, Alan Cox wrote:
> On Thu,  6 Dec 2012 22:26:28 +0400
> Pavel Shilovsky <piastry@...rsoft.ru> wrote:
> 
> > 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).
> 
> If I have my root fs on NFS then the same applies does it not.
> 
> Your patches fail to describe the security semantics and what file rights
> I must have to apply each option. How do I track down a lock user, what
> tools are provided ? How do the new options interact with the security
> layer?
> 
> I don't have a problem with the idea, but it needs a lot more clear
> description of how it works so the model can be checked and if need be
> things tweaked (eg needing write to denywrite etc)

And this is where things get really ugly of course :-).

For the CIFSFS client they're expecting to be able to
just ship them to a Windows server, where they'll
get the (insane) Windows semantics. These semantics
are not what would be wanted on a local filesystem.

So unless we just say "these things have Windows
semantics" (where openers of files can lock out others
under dubious circumstances) there'll be this horrible
difference between (I'm assuming) the sane semantics that
are defined for local filesystems and the insane ones
that you get when you're connecting remotely.

I don't know a good way to fix that, but I'm pretty
sure you don't want the Windows semantics defined
locally :-).

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/