© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
@LocutusOfBorg, can you please tell me exactly what you need? From looking at
git clone https:/
git checkout debian/4.5.1-3
none of the patches that I've pushed upstream are available in this repo.
For this to work you'd need:
1.
commit 78d2a73273786bd
Author: Christian Brauner <email address hidden>
Date: Wed Mar 22 18:16:52 2017 +0100
handle pty device from different namespace
Various programs that deal with namespaces will use pty devices that exist in
another namespace. One obvious candiate are containers. So far ttyname() was
incorrectly handling this case because the pts device stems from the host and
thus cannot be found amongst the current namespace's /dev/pts/<n> entries.
Serge Hallyn and I recently upstreamed patches to glibc that allow ttyname{_r}()
to correctly handle this case. At a minimum, ttyname{_r}() will set errno to
ENODEV in case it finds that the /dev/pts/<n> device that the symlink points to
exists in another namespace. This commit will allow screen to handle this case
and behave correctly in a container.
Signed-off-by: Christian Brauner <email address hidden>
2.commit 7e755ed62d311b0
Author: Christian Brauner <email address hidden>
Date: Wed Apr 5 14:24:22 2017 +0200
screen: handle pts devices in different namespaces
Various programs that deal with namespaces will use pty devices that exist in
another namespace. One obvious candidate are containers. So far ttyname() was
incorrectly handling this case because the pts device stems from the host and
thus cannot be found amongst the current namespace's /dev/pts/<n> entries.
Serge Hallyn and I recently upstreamed patches to glibc that allow ttyname{_r}()
to correctly handle this case. At a minimum, ttyname{_r}() will set errno to
ENODEV in case it finds that the /dev/pts/<n> device that the symlink points to
exists in another namespace.
(The next comment is a little longer but tries to ensure that one can still
understand what is going on after some time has passed.)
In case we detect that ttyname{_r}() returns NULL and sets errno to ENODEV we
have ample reason to assume that the pts device exists in a different
namespace. In this case, the code will set a global flag indicating this case
to true. Furthermore, all operations (e.g. chmod(), chown(), etc.) will now
need to operate on the symbolic link /proc/self/fd/0 directly. While this
sounds straightforward, it becomes difficult to handle this case correctly when
we reattach to an already existing screen session from a different pts device
than the original one. Let's look at the general reattach logic a little
closer:
Assume we are running a shell that uses a pts device from a different
namespace:
total 0
total 0
(As one can see /dev/pts/6 does not exist in the current namespace.)
Now, start a screen session in this shell. In this case this patch will have
screen directly operate on /proc/self/fd/0.
Let's look at the attach case. When we attach to an existing screen session
where the associated pts device lives in another namespace we need a way to
uniquely identify the pts device that is used and also need a way to get a
valid fd when we need one. This patch solves this by ensuring that a valid file
descriptor to the pts device is sent via a unix socket and SCM_RIGHTS to the
socket and display handling part of screen. However, screen also sends around
the name of the associated pts device or, in the case where the pts device
exists in another namespace, the symlink /proc/self/fd/0. But after having sent
the fd this part of the codebase cannot simply operate on /proc/self/fd/0 since
it very likely refers to a different file. So we need to operate on
/proc/
been tricked into operating on a tampered with file or device. So we cannot
simply sent /proc/self/fd/0 via the unix socket. Instead we read the contents
of the symbolic link /proc/self/fd/0 in the main function and sent it via the
unix socket. Then in the socket and display handling part of screen, we read
the contents of the /proc/self/
the pts device names. If they match we know that everything is well. However,
now we also need to update any tty handling code to directly operate on
/proc/
Signed-off-by: Christian Brauner <email address hidden>
3.
commit bab73f99a2dc996
Author: Christian Brauner <email address hidden>
Date: Thu Apr 13 15:55:11 2017 +0200
add compat layer to handle both fifos and sockets
So far screen could only support either sockets or fifos but not both. This
proved to be a blocker for any upgrade. This adds a compatibility layer to
screen v4 to support both sockets and fifos at the same time. The strategy here
is to only support fifos for legacy sessions that already exist. All new
sessions will use sockets by default.
Signed-off-by: Christian Brauner <email address hidden>
For all three patches I've appended version for the Ubuntu package and upstream.
Are you saying you'd need all three ported to screen 4.5.1-3 based on the repo I
pointed out above? I'd like to have this settled before potentially shuffling
a thousand lines of code around.