bootupd: add --pty when stdin is a terminal

[HuijingHei]

From Colin's pointer:
systemd-run breaks when forwarding a physical (/dev/tty* with
label tty_device_t) as opposed to virtual console (/dev/pts
with label user_devpts_t).
When stdin is a terminal, we should definitely use -t.

Fixes #902

[HuijingHei]

Build and test on rhcos:

$ cosa run -c
[root@cosa-devsh work]# env SYSTEMD_LOG_LEVEL=debug systemd-run --pipe bootupctl status
Bus n/a: changing state UNSET → OPENING
sd-bus: starting bus by connecting to /run/dbus/system_bus_socket...
Bus n/a: changing state OPENING → AUTHENTICATING
Bus n/a: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 siga
Got message type=method_return sender=org.freedesktop.DBus destination=:1.21 path=n/a interface=n/a member=n/a cookie=4294967295 reply_cookie=1 signature=s error-name=n/a ea
Bus n/a: changing state HELLO → RUNNING
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=StartTransiena
Bus n/a: changing state RUNNING → CLOSING
Failed to start transient service unit: Connection reset by peer
Bus n/a: changing state CLOSING → CLOSED

[root@cosa-devsh work]# bootupctl status
Running as unit: bootupd.service
Press ^] three times within 1s to disconnect TTY.
Component BIOS
  Installed: grub2-tools-1:2.06-104.el9_6.x86_64
  Update: At latest version
Component EFI
  Installed: grub2-efi-x64-1:2.06-104.el9_6.x86_64,shim-x64-15.8-3.el9_4.x86_64
  Update: At latest version
No components are adoptable.
CoreOS aleph version: 419.96.202504150446-0
Boot method: BIOS

[HuijingHei]

Run cosa without -c:
$ cosa run --qemu-image data/rhcos-419.96.202504150446-0-qemu.x86_64.qcow2 -m 4096 --bind-ro ./,/run/work

Then update bootupd (built within rhel) that includes the patch, run bootupctl status, seems also detect as terminal, see that we have Press ^] three times within 1s to disconnect TTY..
IMU, if only running with -c, it would add --pty; without -c, it should not add --pty, is this right? Does this mean the condition (using nix::unistd::isatty(std::io::stdin().as_raw_fd())) is not correct?

[root@cosa-devsh work]# rpm-ostree usroverlay 
[root@cosa-devsh work]# rm -f /usr/libexec/bootupd && rm -f /usr/bin/bootupctl
[root@cosa-devsh work]# cp bootupd /usr/libexec/bootupd && ln -f /usr/libexec/bootupd /usr/bin/bootupctl
[root@cosa-devsh work]# bootupctl status
Running as unit: bootupd.service
Press ^] three times within 1s to disconnect TTY.
Component BIOS
  Installed: grub2-tools-1:2.06-104.el9_6.x86_64
  Update: At latest version
Component EFI
  Installed: grub2-efi-x64-1:2.06-104.el9_6.x86_64,shim-x64-15.8-3.el9_4.x86_64
  Update: At latest version
No components are adoptable.
CoreOS aleph version: 419.96.202504150446-0
Boot method: BIOS

Without the patch, run bootupctl status without error:

[core@cosa-devsh ~]$ sudo bootupctl status
Running as unit: bootupd.service
Component BIOS
  Installed: grub2-tools-1:2.06-104.el9_6.x86_64
  Update: At latest version
Component EFI
  Installed: grub2-efi-x64-1:2.06-104.el9_6.x86_64,shim-x64-15.8-3.el9_4.x86_64
  Update: At latest version
No components are adoptable.
CoreOS aleph version: 419.96.202504150446-0
Boot method: BIOS

[cgwalters]

Does this mean the condition (using nix::unistd::isatty(std::io::stdin().as_raw_fd())) is not correct?

That looks right to me offhand. (btw though I prefer rustix over nix personally, and in this case the rustix api is slightly cleaner. But anyways that's a basically irrelevant aside.

IMU, if only running with -c, it would add --pty; without -c, it should not add --pty, is this right?

No, both physical and virtual consoles are ttys. I am not sure there's really a way to find out the difference short of scraping /proc/self/fd/0 and seeing whether it's a symlink to /dev/pts/<something> or not.

[cgwalters]

I think I was wrong, there's no real value in us allocating a new pty when we're already on a tty and doing so is just a workaround. So if the selinux fix is going to take some time, then we could do the above logic (detect physical tty and allocate a pty). Or we could just leave this as a known corner case issue that I think relatively few people will hit.

[HuijingHei]

So if the selinux fix is going to take some time, then we could do the above logic (detect physical tty and allocate a pty). Or we could just leave this as a known corner case issue that I think relatively few people will hit.

I am OK to leave this as it is and wait for https://issues.redhat.com/browse/RHEL-86925 is fixed, WDYT, @dustymabe ?

[dustymabe]

I am OK to leave this as it is and wait for https://issues.redhat.com/browse/RHEL-86925 is fixed, WDYT, @dustymabe ?

SGTM. Feel free to close this PR and the open issue.