[systemd-bugs] [Bug 70290] New: [systemd-nspawn] Doesn't correctly handle std{in, out} not being the same file, and not being a TTY

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70290

          Priority: medium
            Bug ID: 70290
          Assignee: systemd-bugs at lists.freedesktop.org
           Summary: [systemd-nspawn] Doesn't correctly handle std{in,out}
                    not being the same file, and not being a TTY
        QA Contact: systemd-bugs at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: lukeshu at sbcglobal.net
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: general
           Product: systemd

This is actually a large, compound bug that results in "it doesn't do the right
thing if you redirect stdio".

Bugs 1-2 mean redirecting stdout doesn't work correctly.
Bug 3 means that redirecting/closing stdin doesn't work correctly.
(possible) Bug 4 means that even if bug 3 is fixed, redirecting stdin doesn't
work as expected.
(possible) Bug 5 means that even if bugs 1-2 are fixed, redirecting stdout
doesn't work as expected.

A quick note on nomenclature: systemd-nspawn creates/acquires a PTY that is
used for /dev/console in the chroot. I will refer to this as the "proxy PTY".

Bug 1: It bases the dimensions of the proxy PTY off of the dimensions of stdin,
not stdout.

This is a 1-line change, to change `ioctl(STDIN_FILENO, TIOCGWINSZ, &ws)` to
use `STDOUT_FILENO`.

Bug 2: It sets the output properties of stdin (if it is a TTY).

This is wrong if stdin and stdout are not the same file.  It gets stdin's
terminal attributes (tcgetattr), runs the through cfmakeraw, and saves them
back (tcsetattr).  The problem is that cfmakeraw sets both input and output
attributes.  The simplest work-around is to set `raw_attr.c_oflag =
saved_attr.c_oflag` after running `cfmakeraw(&raw_attr)`.

(PS: it also unset the ECHO local flag on raw_attr after running it through
cfmakeraw, which already did that.  That line was superfluous.)

But then, the output properties of stdout are not set--we must then do a
similar process for it, but resetting attr.c_iflag, attr.c_lflag, and
attr.c_cc.

We must also, set one before starting to set the other (set stdin before
reading the current values for stdout), or the second write will reset the
first one.

Bug 3: If stdin is not a TTY, it has no form of signal handling.

(the following applies to all signals that a TTY may generate, but I will only
speak of SIGINT)

The "signal handling" currently employed is "hey, stdin, if you see C-c, don't
send me SIGINT, just let me read C-c as input" (through the call to cfmakeraw
mentioned above).  It then passes C-c to the proxy PTY, which translates it
into a SIGINT to be sent to the child process.

This means two things: 1) If stdin isn't a TTY, it's "signal handling" won't
work. 2) If it receives a "signal" from anything other than a terminal, it
won't respond correctly.

So, what happens if the signal handling isn't working.  When it receives
SIGINT, it dies, it stops proxying data between the proxy PTY and stdin/stdout.
 This causes either the child process to starve on stdin, or fill the proxy
PTY's buffer and block.  Either way, it causes an I/O block, and the child
process(es) will need to be kill(1)ed.

The simplest work-around would be to open /dev/tty, and set *that* to not
interpret C-c as SIGINT; that way the TTY is set even if it isn't stdin. 
However, that only fixes consequence 1 above, not consequence 2.

(possible) Bug 4: If stdin is not a TTY, it does not read stdin.
(possible) Bug 5: If stdout is not a TTY, it represents stdout as a TTY to the
child process.

In my opinion, the correct behaviour here would be to set up the proxy PTY as
/dev/console in the chroot, but not set it to stdin/out/err.  Instead, open a
pipe that is used to proxy between the child process' I/O, and systemd-nspawn's
I/O.

Whether or not you agree with that, if stdin is open, I don't think it's
reasonable to ignore it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20131008/ec84380f/attachment-0001.html>