linux-kernel - Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

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, 02 Jun 2016 16:23:36 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg KH <greg@...ah.com>,
	Peter Hurley <peter@...leysoftware.com>,
	Andy Lutomirski <luto@...capital.net>, security@...ian.org,
	"security\@kernel.org" <security@...nel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	"security\@ubuntu.com \>\> security" <security@...ntu.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Willy Tarreau <w@....eu>,
	Aurelien Jarno <aurelien@...el32.net>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jann Horn <jann@...jh.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Slaby <jslaby@...e.com>,
	Florian Weimer <fw@...eb.enyo.de>,
	Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

"H. Peter Anvin" <hpa@...or.com> writes:

> On 06/02/16 13:22, Eric W. Biederman wrote:
>> 
>> The problem with lookup_one_len_unlocked is that it still calls
>> inode_permission.
>> 
>> As per previous discussions we don't want the path based permission
>> checks involved in that lookup.
>> 
>
> Is it that we don't *want* it, or that we don't *need* it?  In the
> latter case, we could just do whatever makes the code simpler, no?

We certainly don't need the permission check.

Keeping the permission check appears to introduce an inconsistency
between what make sense for the code to do and what the code actually
does that only matters once in a blue moon.

That weirdness will probably cause an issue for someone sometime that
will take forever to track down, because no one will be expecting it.

So in my opinion the code will be much more maintainable if we don't
include user visible behaviors that will violate peoples simple mental
model of how the code behaves.

Eric