Fix unreadable output in upgrade log

[dkubek]

This commit resolves an issue where unwanted escape sequences (e.g., ANSI codes) appear in the output of certain commands like dnf during upgrades.

The issue seems to arise because, starting with version 242, systemd-nspawn introduced new pseudo-TTY capabilities (see the Input/Output Options section in systemd-nspawn(1)). As a result, commands run within container may include these escape sequences.

To address this, pseudo-TTY support is explicitly disabled in systemd-nspawn for upgrades on RHEL9 and later.

JIRA: RHEL-69829

[github-actions]

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

• review please @oamg/developers to notify leapp developers of the review request
• /packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build.
However, here are additional useful commands for packit:

• /packit test to re-run manually the default tests
• /packit retest-failed to re-run failed tests manually
• /packit test oamg/leapp#42 to run tests with leapp builds for the leapp PR#42 (default is latest upstream - main - build)

Note that first time contributors cannot run tests automatically - they need to be started by a reviewer.

It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal and kernel-rt, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:

• /packit test --labels kernel-rt to schedule kernel-rt tests set for all upgrade paths
• /packit test --labels beaker-minimal-8.10to9.4,kernel-rt-8.10to9.4 to schedule kernel-rt and beaker-minimal test sets for 8.10->9.4 upgrade path

See other labels for particular jobs defined in the .packit.yaml file.

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

[dkubek]

Also note that there is a warning in the man page for using --pipe

Note that the pipe mode should be used carefully, as passing arbitrary file
descriptors to less trusted container payloads might open up unwanted interfaces for access by
the container payload. For example, if a passed file descriptor refers to a TTY of some form,
APIs such as TIOCSTI may be used to synthesize input that might be used for escaping the
container. Hence pipe mode should only be used if the payload is sufficiently trusted or when the
standard input/output/error output file descriptors are known safe, for example pipes.

Is this applicable to us?

[dkubek]

Another consideration, this issue will arise on any system with nspawn version at least 242. Should we check instead the systemd-nspawn version when adding the argument instead of checking the source version? I am also not sure how feasible would that be at this level.

[pirat89]

Another consideration, this issue will arise on any system with nspawn version at least 242. Should we check instead the systemd-nspawn version when adding the argument instead of checking the source version? I am also not sure how feasible would that be at this level.

@dkubek great job! Checking the system version is ok. Systemd will not be rebased in RHEL 8 and we are sure that RHEL 9 will not contain any older systemd version. Staying with the system version check is ok from this POV. Let's keep it simple.

[pirat89]

Also note that there is a warning in the man page for using --pipe

Note that the pipe mode should be used carefully, as passing arbitrary file
descriptors to less trusted container payloads might open up unwanted interfaces for access by
the container payload. For example, if a passed file descriptor refers to a TTY of some form,
APIs such as TIOCSTI may be used to synthesize input that might be used for escaping the
container. Hence pipe mode should only be used if the payload is sufficiently trusted or when the
standard input/output/error output file descriptors are known safe, for example pipes.

Is this applicable to us?

hmm.. not sure I understand it right. As far as I understand this, it should not affect us as we consider the container fully trusted as we created them and we know what we are executing. The question could be what if a user create custom actor calling custom / third party apps. But that is not different from the situation when we would like to operate without container at all and we use the container just to be able to affect the host system using tooling from the target OS. If someone is able to put malign content into the container, why they would need to escape from it when they could affect the system from inside already?

[pirat89]

lgtm and works as expected \o/ (tested manually). good job!