linux-kernel - Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

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:	Wed, 4 Sep 2013 03:00:13 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Ian Kent <raven@...maw.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	rui.xiang@...wei.com, autofs mailing list <autofs@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] autofs4 - fix device ioctl mount lookup

On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote:

> Ewwww...   NAK in that form.  Just what will happen if the last component
> given to that sucker will be . or .., for starters?  Or a symlink, with
> '/' added to it to force following the damn thing?

OK, in more details:
	* we are changing a user-visible ABI here - kern_path() with
LOOKUP_FOLLOW had been there since the introduction of that misc
device (OK, it used to be path_lookup(), but that changes nothing).
IOW, we used to follow symlinks there, now we do not.
	* pathname may end on more than one slash.  Modified that
way, the code won't do anything good (not to mention that d_lookup()
on an empty string is an interesting torture test for fs/dcache.c;
probably you'll just find nothing, but normally the function is never
called with such arguments, so...).  In any case it's an ABI change.
	* pathname may end with something/. or something/..; again,
d_lookup() won't find you anything now, so we have an ABI change.

That aside, I'm really not happy with this kind of games; this stuff clearly
belongs in fs/namei.c where we can simply see the last component.  Doing that
on the level of "let's scan the pathname for slashes, etc." is just plain
wrong.  Let's step back for a minute here; what are you trying to do?
You have a pathname that should resolve to a mountpoint, without triggering
automount (or crossing into the mountpoint, for that matter) and you want
struct path for the bottom of that mount stack?  Or is it something
completely different?
--
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/