linux-kernel - Re: [PATCH 14/16] vfs: Implement mount_super

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: <40B4F95A-2277-4CFF-B587-782F2DE5DCE4@zytor.com>
Date:	Tue, 19 Apr 2016 11:55:35 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	ebiederm@...ssion.com,
	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Andy Lutomirski <luto@...capital.net>, security@...ian.org,
	"security@...nel.org" <security@...nel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	"security@...ntu.com >> security" <security@...ntu.com>,
	Peter Hurley <peter@...leysoftware.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>, Greg KH <greg@...ah.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jiri Slaby <jslaby@...e.com>, Florian Weimer <fw@...eb.enyo.de>
Subject: Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebiederm@...ssion.com wrote:
>Linus Torvalds <torvalds@...ux-foundation.org> writes:
>
>> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman
>> <ebiederm@...ssion.com> wrote:
>>> The devpts filesystem has a notion of a system or primary instance
>of
>>> devpts.  To retain the notion of a primary system instance of devpts
>>> the code needs a way to allow userspace to mount the internally
>>> mounted instance of devpts when it is not currently mounted by
>>> userspace.  The new helper mount_super_once allows that.
>>
>> This is where I stopped reading this patch series.
>>
>> No.
>>
>> We want to get *rid* of the idiotic "primary instance" crap.
>
>That is actually pretty much the opposite of what you said last time,
>but having looked at the cost to maintian a "primary instance" notion
>and what will break if we don't I am happy to remove such a notion
>from devpts.
>
>> The whole and only point of doing the "which pts filesystem am I
>> associated with" for ptmx is to stop the idiotic "one devpts is
>> pecial".
>>
>> I don't want to see 16 random patches.
>>
>> I want to see *one* patch that makes /dev/ptmx look up the pts
>> filesystem, and be done with it.
>
>Now that I know where most of the landmines are in userspace I
>performed
>some limited testing to see to see what the implications are:
>
>Causing every userspace mount of devpts to use mount_nodev means the
>following:
>
>- Support for reserving ptys for the system devpts instance using
>  /proc/sys/kernel/pty/reserve needs to be removed.
>
>- On CentOS6 devpts will wind up mounted twice /dev/pts.
>
>- Open of /dev/ptmx can use devpts_mnt to find the devpts filesystem.
>
>In my cursory testing userspace still boots and works desipite those
>changes so I am quite happy to go down this path.
>
>Eric

On a totally different subject: I'm still quite unhappy with the pty number assignment policy.  We had to move away from a completely circular policy because of glibc issues in the handling of utmp, which may or may not have been fixed since, but the current policy of always allocating the lowest number is absolutely pessimal for accidental references to a stale pty.

At the time, I suggested that we'd go with a circular policy within the used high water mark, which would still work around the glibc problem; another option would be to quarantine a pty number for a time before reallocation.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.