linux-kernel - Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

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: <20150515025102.GI7232@ZenIV.linux.org.uk>
Date:	Fri, 15 May 2015 03:51:03 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeremy Allison <jra@...ba.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Neil Brown <neilb@...e.de>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks

On Thu, May 14, 2015 at 07:18:16PM -0700, Linus Torvalds wrote:
> The only difference - EVER - would be if you pass in the ICASE flag.
> Nothing I suggested would change semantics without it (the _hash_
> changes, but that doesn't change semantics, it's a purely internal
> random number).
> 
> Now, *with* O_ICASE/AT_ICASE, semantics change. Obviously. At that
> point the dentry lookup would match case-insensitively.
> 
> For example, let's say that you have a directory where you already
> have both "Blah" and "blah", because you created them in a sane
> environment. They'll be two different dentries (assuming they are
> cached), but they'll have the same dentry hash.
> 
> Now, you open "blah" with O_ICASE, and the end result is that you
> would randomly open one or the other (it would be the one you find
> first on the hash chain). Tough. Mixing icase and case-insensitive is
> by definition going to cause those kinds of issues.

With c-i mount, unpacking a tarball with tar(1) will not (silently, at that)
create a situaiton when your c-i users will get lookups proceeding into
randomly picked variant of directory, with variants differing only in
case.  It will do the right thing and put the files where they would be
expected, giving an expected "it already exists" if you try to create
a directory with the name that matches that of existing file, etc.
With this, OTOH, you'll have to use specialized tools for creating
files in that tree, or risk random lossage, because creating /mnt/foo/bar
when /mnt/Foo/Bugger already existed will succeed just fine, leaving one
hell of a mess for c-i users.

What's the benefit compared to c-i mount?  Not hitting filesystem's
->d_hash() and ->d_compare()?
--
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/