[Bug 1669578] Re: Get ttyname() to work properly in containers

Axel Beckert abe at debian.org
Tue Mar 28 20:10:27 UTC 2017


Hi Michael,

Michael Sparmann wrote:
> That ifndef has been removed from upstream code in
> http://git.savannah.gnu.org/cgit/screen.git/commit/?id=d965ff1d92e2bd57d24b68cfbd6990486024baa3
> almost 2 years ago, but that apparently hasn't landed in the ubuntu
> package yet.

That commit is only present in the master branch which is the
developement branch for a potential Screen 5.x series.

But that branch iss far from stable. Debian and Ubuntu currently track
the screen-v4 stable branch — which still has that code.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1669578

Title:
  Get ttyname() to work properly in containers

Status in glibc package in Ubuntu:
  Fix Committed
Status in screen package in Ubuntu:
  Fix Released
Status in tmux package in Ubuntu:
  Triaged

Bug description:
  For the past year or so, the LXD team has been trying to resolve an
  issue affecting screen, tmux and a bunch of other software (including
  the "tty" command).

  The problem comes from the fact that when attaching to a container,
  your terminal's pts device comes from the host and therefore can't be
  found in /dev/pts/.

  glibc makes the assumption that it can readlink /proc/self/fd/0 and
  that the target path will exist. This simply isn't true as the symlink
  target returned by the kernel, is confusingly relative to the host's
  root and not the container's.

  Which means that if the target happens to exist, it's actually going
  to be an entirely different pts device from the one that you're
  actually attached to.

  
  You therefore need to do something along the lines of:
   - Resolve the symlink. If the target doesn't exist, return the symlink as the ttyname.
   - If the target does exist, check that its major and minor matches that of the symlink itself, if it doesn't, then return the symlink rather than the target.

  
  That's the ideal approach which makes existing software keep working properly without the need for any added code. After about a year of bikeshedding, the proposed glibc upstream fix has now evolved to instead returning ENODEV in the is_pty function. This allows downstream glibc users to detect this case and then use /proc/self/fd/0 rather than the return value of ttyname() but means every software using ttyname() now needs fixing.

  As we very much care about Ubuntu running properly inside LXD
  containers, our suggested patchset includes both the ENODEV patch as
  is still being considered by upstream (stuck on legal validation) AND
  another patch which has ttyname() return the symlink when it receives
  the ENODEV.

  
  We feel this is the best way to fix the problem entirely right now. Once glibc upstream merges the ENODEV side of this and all affected software get fixed upstream to deal with it, we'll then be able to drop that patch without causing any regressions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1669578/+subscriptions



More information about the foundations-bugs mailing list