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:   Wed, 23 Aug 2017 18:32:49 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Stefan Lippers-Hollmann <s.l-h@....de>,
        Christian Brauner <christian.brauner@...onical.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 23, 2017 at 6:25 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
>
> The new behavior is that when we open ptmx we cache a path the slave
> pty.

Yes. It's not strictly "new", though - we've done that for a while,
and if you used /dev/pts/ptmx you'd even have had the *right* path
for a while ;)

And this exact issue that Stefan is reporting.

But nobody ever used /dev/pts/ptmx, so nobody got the right path, and
nobody kept an extra reference to the pts mount.

> If instead of caching that path we call devpts_acquire to compute the
> mount point of the dentry we should be able to skip caching mountpoint
> in ptmx_open.

Yes, that's my plan - get rid of the 'struct path' entirely, make
'driver_data' point to just the dentry, and then at TIOCGPTPEER time
just re-create the path by looking up the vfsmount again (by doingf
that "pts" lookup again)

It should all be _fairly_ straightforward, but it's definitely a
rather bigger change than that "just fix the path" patch was.

Anyway, it's already reverted in my tree, I'll push it out after I've
verified that there isn't some silly build issue (there won't be, but
I've been burned by "this is obviously correct" too many times, so now
I always build before pushing anything out unless I'm on my laptop of
something when it's just too inconvenient).

                      Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ