linux-kernel - Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5)

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] [day] [month] [year] [list]

Date:	Sun, 10 Jan 2010 04:42:26 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Pavel Machek <pavel@....cz>
Cc:	Jeff Layton <jlayton@...hat.com>,
	Jamie Lokier <jamie@...reable.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	miklos@...redi.hu
Subject: Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks
	and file bind mounts (try #5)

On Fri, Jan 01, 2010 at 04:40:27PM +0100, Pavel Machek wrote:
> > Access rights belong to file, not to a pathname (and there's no such thing
> > as _the_ pathname of a file).
> > 
> > I'd buy that as a minor QoI issue; as a security one - no way.
> 
> Ok, so you see it as a (QoI) problem, but not too major. Good; I hope
> it gets fixed one day.

Actually, I'm not even sure that it *is* worse than what we'd get after
such change.  Note that it's not just about trying to reopen a file
currently opened r/o for write; there's the opposite case.  We'd break
scripts that try to read /dev/stderr and expect to be called with stderr
redirected to caller-writable file.  With redirects done with 2> and not
2<>.  Sure, it's a lousy practice.  And scripts in question are not
well-written in general.  Downright unmaintainable, in fact.  Written
by sysadmin that had left the job five years ago and can't be located,
even if he could be bribed into touching That Shite(tm) ever again.

We have far lousier kinds of behaviour we can't fix for compatibility
reasons.  O_CREAT on dangling symlinks, for one.  We tried to switch to
sane variant (from the current "create file wherever that symlink points
to") and had to revert due to userland crap that actually relied on that
insanity.
--
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/