One of the biggest advantages of running as root is the ability to have
all the UIDs from the host operating system mapped into the container
by using the host's user namespace.
This can be a big help when faced with permission problems.
https://github.com/containers/toolbox/issues/267
This is one more step towards enabling toolbox(1) to be run as root.
When invoked as 'sudo toolbox' there's no XDG_RUNTIME_DIR available for
the root user. Neither the environment variable nor the directory are
present.
XDG_RUNTIME_DIR is used for two reasons. First, to place the 'lock'
file to synchronize Podman migrations and the initialization stamp
file to synchronize the container's entry point with the user-facing
'enter' command running on the host. Second, it's used to propagate
things like the user D-Bus, Pipewire and Wayland sockets.
The first use-case is important for toolbox(1) itself to work. When
running as root, XDG_RUNTIME_DIR is replaced with /run/toolbox for this
purpose.
The second use-case is mostly ignored because sudo(8) doesn't create
a full-fledged user session. Graphical applications can still work by
connecting to a X11 server over the local abstract socket or the file
system socket in /tmp/.X11-unix.
https://github.com/containers/toolbox/issues/267
Currently, XDG_RUNTIME_DIR only gets propagated into the toolbox
container from the host during 'enter'. This means that the
container's entry point doesn't know about it. So, there's code in
'init-container' that sets XDG_RUNTIME_DIR to /run/user/UID.
However, this assumption might not always hold true for all host
operating systems. Given that XDG_RUNTIME_DIR plays a crucial role in
synchronizing the container's entry point with the user-facing 'enter'
command running on the host, it's wise to try a bit harder to
propagate the value of XDG_RUNTIME_DIR into the container.
Note that it can still go wrong if the value of XDG_RUNTIME_DIR
changes after the container was created because the entry point will
still have the old value. Fortunately, this isn't something that
happens too often under normal operation.
The value of XDG_RUNTIME_DIR is still propagated during 'enter' to
retain compatibility with existing toolbox containers.
https://github.com/containers/toolbox/issues/267
... by running updatedb(8) on start-up and then at 24 hour intervals
from there on.
This isn't as nice as using a systemd.timer(5) because the current
timer goes away when the toolbox container is stopped and is rearmed
when it's started. Therefore, repeatedly restarting a container will
also run updatedb(8) again and again.
Fortunately, this isn't so bad with updatedb(5) implementations that
are able to incrementally update the database [1], which is what Fedora
uses.
The 24 hour interval was chosen based on the systemd.timer(5) settings
used by Fedora's mlocate RPM.
[1] https://pagure.io/mlocatehttps://github.com/containers/toolbox/issues/391
'toolbox enter' attempts to run the user's preferred shell as a login
shell by passing it the '-l' argument. However, when the user's
preferred shell is missing from the toolbox container and it falls
back to Bash, then it was no longer a login shell because the '-l'
argument went missing.
https://github.com/containers/toolbox/pull/588
It's necessary to propagate the XAUTHORITY environment variable from
the host when an X11 client is run as 'sudo <some-client>'. If an X11
client is started inside a 'su -' session, then xauth(1) needs to be
present so that pam_xauth.so can add a new XAUTHORITY environment
variable to the 'su -' session.
https://github.com/containers/toolbox/pull/572
Using the word 'unprivileged' confuses readers because it means
different things to different people. eg., it can mean 'rootless' or
'sandboxed', which are quite different things. It becomes even more
confusing given the ongoing work to make 'sudo toolbox ...' work.
It's nice to mention that Toolbox is targetted at Linux operating
systems and that it relies on standard container technologies from OCI.
https://github.com/containers/toolbox/pull/597
... that were created to have a bind mount at /run/host/monitor. Newly
created containers no longer need org.freedesktop.Flatpak.SessionHelper
and hence the D-Bus service doesn't need to be started for them.
https://github.com/containers/toolbox/issues/267
This is one more step towards enabling toolbox(1) to be run as root.
When invoked as 'sudo toolbox ...' there's no user or session D-Bus
instance available for the root user, which prevents the use of D-Bus
services like org.freedesktop.Flatpak.SessionHelper.
The code is forgiving to runtime errors when reacting to file system
events because it's not worth abruptly terminating the entry point
because of what might be a passing error. However, it's a lot stricter
when initially configuring the container because the failure mode isn't
as surprising for the user and it's worth starting from a valid state.
https://github.com/containers/toolbox/issues/267
This is one more step towards enabling toolbox(1) to be run as root.
When invoked as 'sudo toolbox ...' there's no user or session D-Bus
instance available for the root user, which prevents the use of D-Bus
services like org.freedesktop.Flatpak.SessionHelper.
https://github.com/containers/toolbox/issues/267
When I added the test that looked at the logs of a toolbox, I did not
realize that the startup of a toolbox takes some time. That caused the
CI to flake even more than usual.
The solution I used was inspired by a helper function in Podman's test
suite (WaitContainerReady()).
https://github.com/containers/toolbox/pull/594
When the host's /dev directory is bind mounted into the toolbox
container, then pseudo-terminal devices created for the container have
their group ownership set to 'nobody'.
This is because bind mounting /dev also pulls in the devpts file
system at the host's /dev/pts, which is owned by the 'tty' group on the
host. Since this GID is not available inside the container, it's
represented as 'nobody'.
This can be addressed by mounting a fresh devpts file system inside the
toolbox container. It ensures that pseudo-terminal devices created for
the container are owned by the container's 'tty' group.
As suggested by Giuseppe Scrivano.
https://github.com/containers/toolbox/pull/581
On Ubuntu, both /usr/share/terminfo and /lib/terminfo can have contents, and xterm-256color is at /lib/terminfo (provided by ncurses-base package) while xterm+256color is at /usr/share/terminfo (provided by ncurses-term package). This PR checks both directory to suppress the warning.
Some users tend to put random throwaway files in /tmp, so having that
location shared across the host operating system and toolbox containers
makes it a more pleasant user experience.
One nice side-effect of this is that it also makes the local file
system socket in /tmp/.X11-unix used by X11 clients available to
toolbox containers. So far, X11 clients inside toolbox containers used
the local abstract socket. However, since GNOME 3.38, Mutter no longer
listens on the abstract socket and only uses the file system socket to
start the Xwayland server [1]. Therefore, this makes it possible to
run X11 clients inside toolbox containers running on a GNOME 3.38 host.
[1] Mutter commit e2123768f635ee89
https://gitlab.gnome.org/GNOME/mutter/-/issues/1289https://github.com/containers/toolbox/issues/562
This prevents devices from losing properties that would otherwise be
set on the host operating system. It's useful when developing software
like PipeWire that uses libudev to enumerate devices.
https://github.com/containers/toolbox/issues/468
The redirectPath function used to error out when handling directories,
if the path inside the container was initially absent. There's no real
reason for this, and some containers failed to start because the
/media directory was absent from them. This can happen as a
consequence of Fedora's filesystem RPM failing 'dnf update'
transactions inside containers:
$ toolbox enter f33-to-upgrade
$ dnf --assumeyes --enablerepo=fedora --disablerepo=rawhide update
<...>
Failed:
filesystem-3.14-2.fc32.x86_64
filesystem-3.14-3.fc33.x86_64
Error: Transaction failed
Therefore, it's better to not worry about the path being initially
absent, and be more forgiving and robust.
https://github.com/containers/toolbox/issues/539
Since Podman 2.0.5, containers that were created with
'podman create --userns=keep-id ...' automatically get the user added
to /etc/passwd [1]. However, this user isn't as fully configured as it
needs to be. The home directory is specified as '/' and the shell is
/bin/sh.
Note that Podman doesn't add the user's login group to /etc/group [2].
This leads to the following error message when entering the container:
/usr/bin/id: cannot find name for group ID 1000
It's expected that this will be fixed in Podman itself.
Therefore, the entry point needs to call usermod(8) to update the user,
instead of using useradd(8) to create it.
[1] Podman commit 6c6670f12a3e6b91
https://github.com/containers/podman/pull/6829
[2] https://github.com/containers/podman/issues/7389https://github.com/containers/toolbox/issues/523
... and other hybrid set-ups where the host and container OSes aren't
the same.
The entry point of a toolbox container already runs as root:root.
Therefore, there's no need to run it with an additional group.
Interactive shells spawned by 'sudo su -' both inside the container
and on the host don't run with such an additional group either. They
run just as root:root.
This prevented toolbox containers from starting up on Fedora CoreOS
hosts, because CoreOS has both the 'sudo' and 'wheel' groups but the
fedora-toolbox images only have the 'wheel' group. Therefore, it
ended up calling 'podman create --group-add sudo ...', and since the
'sudo' group was missing from the image, the container failed to start.
The --group-add flag was added in commit 4bda42d414 when the
entry point ran as $USER as specified in the user-specific customized
image. The additional group was specified to retain consistency with
interactive shells run as $USER.
Since then, things have changed. There's no longer any user-specific
customized image and commit f74400f450 made the entry point run
as root:root. The --group-add flag should have been removed as part of
those changes.
https://github.com/containers/toolbox/issues/423
It tries to loosely mimic ncurses to look up a terminfo entry for the
current terminal, as mentioned in the terminfo(5) manual. Unlike
ncurses, it doesn't handle TERMINFO_DIRS, though, to avoid parsing an
array of directories for the sake of simplicity.
Every line of code in this file is part of the interactive shell's
start-up sequence, which makes it a trade-off between correctness and
speed. Therefore, the purpose of this warning is not to exhaustively
catch all possible corner cases, but to serve as a convenience in the
majority of cases. Ultimately, if someone is using an exotic terminal
set-up, then a missing warning is a minor price to pay in order to not
slow things down for the vast majority of users who don't.
Based on code written by Mert Alp Taytak:
https://github.com/containers/toolbox/pull/515https://github.com/containers/toolbox/issues/505
Currently toolbox containers can get misconfigured if some
configuration files on the host are absolute symbolic links to some
other location.
For example, when systemd-resolved is used to manage /etc/resolv.conf
on the host, and if the file is an absolute link to
/run/systemd/resolve/stub-resolv.conf, then /etc/resolv.conf ends up
being invalid inside the container. This happens because the
container's /etc/resolv.conf points to /run/host/etc/resolv.conf, which
in turn points to /run/systemd/resolve/stub-resolv.conf, but that's
absent from the container.
This is, of course, not a problem with relative symbolic links. If the
host had a relative link to ../run/systemd/resolve/stub-resolv.conf,
then it would continue to work inside the container.
One solution would have been to use flatpak-session-helper to maintain
a copy of the host's /etc/resolv.conf in
$XDG_RUNTIME_DIR/.flatpak-helper/monitor. However, that doesn't work
when toolbox(1) is run as root.
The other option is to prepend the destination of the absolute symbolic
link with /run/host to make it resolve inside the container. It might
not work with funky links, but it's enough for the common case where a
an administrator changed the host's /etc/resolv.conf into a sane, but
absolute, symbolic link.
Properly configured hosts should anyway use relative symbolic links,
because they don't need to be adjusted in such scenarios. That's also
what Fedora and Ubuntu do, by default.
Thanks to Tudor Roman for raising a concern about relative symbolic
links.
Based on Martin Pitt's work on the POSIX shell implementation:
https://github.com/containers/toolbox/pull/380https://github.com/containers/toolbox/issues/187
This is based on the output of 'gcc -dM -E - </dev/null' on a ppc64le
system. For what it's worth, the _CALL_ELF macro is defined as 1 on
the big endian variants of the architecture.
The original intention in commit 6ad9c63180 was to support the
architectures that Fedora builds for, and it doesn't care about PowerPC
variants that aren't ppc64le [1].
[1] https://fedoraproject.org/wiki/Architectures/PowerPChttps://github.com/containers/toolbox/pull/536
The /usr/bin/toolbox binary is not only used to interact with toolbox
containers and images from the host. It's also used as the entry point
of the containers by bind mounting the binary from the host into the
container. This means that the /usr/bin/toolbox binary on the host must
also work inside the container, even if they have different operating
systems.
In the past, this worked perfectly well with the POSIX shell
implementation because it got intepreted by whichever /bin/sh was
available.
The Go implementation also mostly worked so far because it's largely
statically linked, with the notable exception of the standard C
library. However, recently glibc-2.32, which is used by Fedora 33
onwards, added a new version of the pthread_sigmask symbol [1] as part
of the libpthread removal project:
$ objdump -T /usr/bin/toolbox | grep GLIBC_2.32
0000000000000000 DO *UND* 0000000000000000 GLIBC_2.32
pthread_sigmask
This means that /usr/bin/toolbox binaries built against glibc-2.32 on
newer Fedoras pick up the latest version of the symbol and fail to run
against older glibcs in older Fedoras.
One way to fix this is to disable the use of any C code from Go by
using the CGO_ENABLED environment variable [2]. However, this can
negatively impact packages like "os/user" [3] and "net" [4], where the
more featureful glibc APIs will be replaced by more limited
equivalents written only in Go.
Instead, since glibc uses symbol versioning, it's better to tell the
Go toolchain to avoid linking against any symbols from glibc-2.32.
This was accomplished by a few linker tricks:
* The GNU ld linker's --wrap flag was used when building the Go code
to divert pthread_sigmask invocations from Go to another function
called __wrap_pthread_sigmask.
* A static library was added to provide this __wrap_pthread_sigmask
function, which forwards calls to the actual pthread_sigmask API in
glibc. This library itself was not linked with --wrap, and
specifies the latest permissible version of the pthread_sigmask
symbol from glibc for each architecture. Currently, the list of
architectures covers the ones that Fedora builds for.
* The Go cmd/link linker was switched to external mode [5]. This
ensures that the final object file containing all the Go code gets
linked to the standard C library and the wrapper static library by
the GNU ld linker for the --wrap flag to kick in.
Based on ideas from Ondřej Míchal.
[1] glibc commit c6663fee4340291c
https://sourceware.org/git/?p=glibc.git;a=commit;h=c6663fee4340291c
[2] https://golang.org/cmd/cgo/
[3] https://golang.org/pkg/os/user/
[4] https://golang.org/pkg/net/
[5] https://golang.org/src/cmd/cgo/doc.gohttps://github.com/containers/toolbox/issues/529
