Package: schroot
Version: 1.6.13-7
I was trying to debug some stuff and found that sometimes in my
schroot sessions `tty` says "not a tty". Further investigations
discovered that schroot now detaches the pty namespace. I don't agree
with this decision. (I also have a mysterious situation where
something gets a Hangup that I am still debugging; IDK if it's related
but it's certainly suspicious.)
Steps
In terminal 1
schroot -b -c forky -n t
schroot -rc t tty
In terminal 2
schroot -rc t tty
Expected results
In terminal 1, the tty of terminal 2 is printed
In terminal 2, the tty of terminal 2 is printed
Actual results
In terminal 1, /dev/console
In terminal 2, not a tty
I'm pretty sure this is something to do with this change:
schroot (1.6.13-4) unstable; urgency=medium
...
* Cherry-pick "Mount a new instance of /dev/pts in the chroot".
Closes: #856877, #983423
I read those bugs and I think what happened was:
Under certain lxc versions, /dev/ptmx and/or /dev/pts are not fully
accessible and/or manipulable to the processes within the container.
It was decided to work around this by changing schroot to detatch the
pty namespace within its chroot, from the outside pty namespace.
I don't agree with this decison.
Firstly, the ramifications of this change don't seem to have been
fully considered. I don't consider this a reasonable change. schroot
is not trying to be a container manager which fully isolates the
programs within it. It's supposed to be an operating system version
overlay manager. schroot's value is in its transparency. Making
schroot sessions more isolated is a regression.
Secondly, this fix ix misconceived. The root cause is that the
environent provided to schroot by lxc is broken. If the pty namespace
needs to be detached, that's lxc's job. schroot is entitled to
assume, since it is supposed to be root in its environment, that it
can manipulate the pty system. (Where, here, "manipulate" means to
pass the ability to manipulate on to its chroots, so that they can run
script or whatever.)
Thirdly, the results don't work properly. See above.
Fourthly, the documentation is inadequate. There isn't even anything
in NEWS.Debian.gz.
Fifthly, there seems to e no way to easily go back to the non-broken
behaviour. In
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983423#84
Simon says that this was
coordinated change to the various profiles' fstab templates
and the 10mount script
I think at the very least, the 10mount script could be modified to
check for the old way of doing things. That way if a user edits the
fstab themselves, to put it back, things will work.
But, really, I think the fix ought to be in lxc. If lxc can't be
fixed, this kind of workaround should be limited so that it takes
effect only within the broken container environments (ie ones where
schroot and its rootly children can't manipulate ptmx/pts normally).
For example, the mount script could note that the situation was busted
and not apply the normal pts bind mount in the fstab, or something.
I have to say that I share Thorsten's frustration, when he writes[1]:
> dev/pts stuff is malfunctioning again,
> after like 15 years of it working
schroot has functioned very well for me for decades. It is
disappointing to find that it has been made to malfunction to work
around bugs in other software - indeed, other software whose marketing
sometimes seems to try to position it as a replacement for schroot,
even though it isn't really.
In the meantime I will look in my etckeeper logs and see if I can undo
this change on my system.
Ian.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983423#34
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
