linux-kernel - Re: RFC: deprecating/removing the legacy mode of devpts

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:	Sun, 8 Apr 2012 09:30:07 +0200
From:	Kay Sievers <kay@...y.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"Ted Ts'o" <tytso@....edu>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Subject: Re: RFC: deprecating/removing the legacy mode of devpts

On Sun, Apr 8, 2012 at 00:03, H. Peter Anvin <hpa@...or.com> wrote:
> On 04/07/2012 02:27 PM, Ted Ts'o wrote:
>> On Sat, Apr 07, 2012 at 01:02:33PM -0700, H. Peter Anvin wrote:
>>> The problem is that the lack of migration at the root causes real
>>> problems for the people who need the extra funkiness, and unlike BSD
>>> ttys it's not an application-level change at all.
>>
>> Could you explain what the issues are?  I haven't been following
>> devpts all that carefully.
>>
>
> The issue is that to make the "ptys are private to an instance of the
> devpts filesystem", /dev/ptmx has to live inside the /dev/pts
> filesystem.  This was traditionally not the case.  To avoid breaking
> everything all at once, we have a legacy mode which supports the "all
> devpts instances are the same" (effectively bind mounts) and which
> support a /dev/ptmx outside /dev/pts.
>
> The problem is that anyone who wants to take advantage of the new
> functionality has to make sure *all* instances of devpts work with the
> new protocol.  This means modifying your distro to:
>
> 1. Add "newinstance" and "ptmxmode" to /etc/fstab [easy]
> 2. Make /dev/ptmx a symlink to /dev/pts/ptmx.
>
> 2 would be easy if it wasn't for udev, which makes it very hard.  It is
> not reasonable for udev to support both modes, so the *only* mode that
> is reasonable for it to support is the new mode.  However, it is
> increasingly obvious that if we don't force it, this will never happen.

I don't think it has much to do with udev, it follows 100%
instructions from the kernel, and it does not create the device node
that is in the way here.

Udev does not name any device in the system since a long time. Since
quite a while it has not even the code to do mknod() and requires
devtmpfs. The device node part of udev these day is limited to manage
device node permissions and creating additional symlinks. All device
node creation happens inside the kernel itself - where it belongs -
and not in userspace.

If the default behaviour of /dev/pts/* should be changed, the kernel
should be changed to support the multi-instance mode right away
without involving userspace. We better do not require userspace to
gain any knowledge about such stuff. I'm confident, that we should not
add more, or require to support multiple alternative ways of handling
kernel internals in userspace.

So, I think we either remove the '/sys/class/tty/ptmx' device from the
system, and let the devpts code create the symlink in the 'devtmpfs'
filesystem, or alternatively the '/sys/class/tty/ptmx' device supports
the multi-instance mode itself, instead of requiring a symlink. Such
stuff belongs entirely into the kernel these day. Anything else seems
to just ask for trouble.

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