Lxd: tty reports 'not a tty'

[smoser]

$ dpkg-query --show lxd lxc
lxc 2.0.0~rc5-0ubuntu1
lxd 2.0.0~rc2-0ubuntu2

$ lxc image list trusty
+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+
| ALIAS  | FINGERPRINT  | PUBLIC |            DESCRIPTION             |  ARCH  |   SIZE   |         UPLOAD DATE         |
+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+
| trusty | 12b57b84ad44 | no     | Ubuntu 14.04 LTS server (20160304) | x86_64 | 118.74MB | Mar 7, 2016 at 2:24pm (UTC) |
+--------+--------------+--------+------------------------------------+--------+----------+-----------------------------+

$ lxc launch trusty t1
$ lxc exec t1 -- tty
not a tty

#  just for the record
$ lxc exec t1 -- sh -c 'test -t 1 && test -t 0 && echo "test -t says yes" || echo "test -t says no"'
test -t says yes

I noticed this when running 'do-release-upgrade -d'. I know i've seen it in some other programs to, but I dont recall. I suspect they all just use 'tty' to check.

[stgraber]

Hi,

This isn't new, in fact we've always had that behavior with LXC as well.

The problem is that when attaching we need to allocate a pts pair for the terminal, as LXD runs as root on the host and must attach to that terminal, it's unsafe for us to allocate it from inside the container as a malicious user could mount whatever they want over /dev/pts in the container and some distros don't always mount it in that location.

As a result, for security reasons we allocate the pts on the host rather than in the container.

The tty tool looks at /proc/self/fd/0 and resolves the symlink, ends up with some /dev/pts/XX but that's a host path rather than a container path, so it can't actually access it and so fails.

It may be possible to fix the "tty" utility itself to work properly in containers and output "/proc/self/fd/0" rather than a /dev/pts path when run in such an environment.

I however don't see a safe way for us to allocate a tty from inside the container in either LXC or LXD, so I expect some other pieces of software to remain just as confused.

[stgraber]

@hallyn

[stgraber]

A workaround for that kind of issue is to run "script /dev/null" which will create a minimal pts proxy for your INSIDE the container and so make tty and other commands happy.

[smoser]

I remembered what other programs I wanted to run in a container which check for tty and fail.
tmux
screen

$ lxc exec t1 screen
Must be connected to a terminal.

[stgraber]

So after doing some more digging, I've noticed that "tty" actually returns true despite the error message.

The problem appears to be with the ttyname C library function which will return an empty string if it can't deref the path to the current tty. One could easily argue that rather than returning that empty string, it should instead return /proc/self/fd/0 so the non-derefed path which would then be a perfectly valid tty path and should make everything happy, including tty, tmux and screen.

[stgraber]

Ok, so I'm going to close this as far as LXD is concerned. I think the real fix is to fix glibc's ttyname() to return /proc/self/fd/0 when it can't deref it to a /dev path.

I did a quick test here with a hacked up libc and it seemed to do the trick, but we'd need a clean upstream fix ideally. Would be nice if you could file a bug against glibc in Ubuntu and subscribe ~ubuntu-lxc to it so we can track it there.

[hallyn]

Note... If /proc/self/fd/0 points to /dev/pts/10 (bc that is the pty
on which you ran 'lxc exec'), and you create 10 ptys in the container
(just ssh in, start tmux, and create 9 windows), then tty will work
after that, and tmux works.

[stgraber]

This is a glibc issue in discussion upstream, there is nothing we can do at the LXD level, so closing this again.