linux-kernel - Re: [PATCH 0/1] devpts: use dynamic

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: <CAPP7u0W5288y+mb0w=LZdJA=OdTVsuByLEhTY2HHtvnytSOeMg@mail.gmail.com>
Date:   Thu, 17 Aug 2017 00:28:45 +0200
From:   Christian Brauner <christian.brauner@...onical.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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>
Subject: Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

On Wed, Aug 16, 2017 at 11:45 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Wed, Aug 16, 2017 at 2:37 PM, Christian Brauner
> <christian.brauner@...onical.com> wrote:
>>> And Christian, if you can beat on this, that would be good.
>>
>> Yes, I can pound on this nicely with liblxc. We have patch
>> ( https://github.com/lxc/lxc/pull/1728 ) up for review that
>> allocates pty fds from private devpts mounts in different namespaces
>> and sends those fds around between different namespaces.
>
> Good. Testing that this works with different pts filesystems in
> different places is exactly the kind of thing I'd like to see. I only
> tested with my single pts filesystem that is mounted at /dev/pts, and
> making sure it works when there are multiple mounts and in different
> places is exactly the kind of testing this should get.

I'm compiling a kernel now and depending on how good the in-flight
wifi is I try to test this right away and answer here if that helps. If the
in-flight wifi sucks it might take me until tomorrow.

>
> For example, if some namespace has it's pty's in _its_ /dev/pts/
> hierarchy, and you then pass such a pty to somebody else that either
> doesn't have that pts mount at all, or has it visible somewhere
> entirely different, the result should now be something else than that
> "/dev/pts/n" path.
>
> But it would be good to just test this in general too, and make sure I
> didn't screw up some reference count or something. The patch *looks*
> obviously correct, but ...
>
>                Linus