linux-kernel - Re: BUG_ON(nd->inode->i_op->follow

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, 12 Mar 2013 11:31:08 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG_ON(nd->inode->i_op->follow_link);

On Sun, Mar 10, 2013 at 4:04 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> The interesting part is what to do with it; it's not enough to make that
> BUG_ON() to STFU, unfortunately.

Why? That's what I did last week, it seemed to be the RightThing(tm)
to do. It somebody has opened a symlink, opening that again through
/proc gives you the same symlink. That would be the natural semantics,
no? You do *not* want to follow it any further, afaik.

And yes, I tested the ENOTDIR semantics too while doing that, and it
seems to be the right thing again. It's not a directory. It's a
symlink.

But hey, if there is some deeper reason for why we'd need to do
anything more that I'm missing, and not just your dislike of the
semantics, thats' fine too.

That said, the thing I think is the *real* bug is that we expose this
O_NOFOLLOW|O_PATH file descriptor through /proc at all. How does that
happen to begin with? Normal O_PATH file descriptors don't do that,
afaik, and they get instantiated as some very special file descriptors
that don't show up as such for most operations. So I think there is
some O_NOFOLLOW magic going on there...

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