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: <87inzdmo9z.fsf_-_@x220.int.ebiederm.org>
Date:	Tue, 19 Apr 2016 13:44:40 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.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>,
	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: Does anyone care about a race free ptsname?

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> What this does is get rid of the horrible notion of having that
>
>     struct inode *ptmx_inode
>
> be the interface between the pty code and devpts. By de-emphasizing the 
> ptmx inode, a lot of things actually get cleaner, and we will have a much 
> saner way forward.

I will take a look in a minute.   Before I do that I want to mention
why I care about /dev/pts/ptmx.

There is a posix function that is widely used called ptsname.  It's
function is to take a master file descriptor and returns the path to the
slave.

All we have in the kernel to support ptsname is an ioctl TIOCGPTN that
returns the pty number in the appropriate instance of devpts.

The only way we have today to query which instance of devpts the pty is
on is through fstat and look st_dev to see if the file is on the correct
filesystem.  This works when /dev/pts/ptmx is used and fails when
/dev/ptmx is used.

Does anyone else care?

If no one cares I will stop worrying about it and just get on with
fixing the rest of this mess which there definitely seems to be the will
to do.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ