It's common practice to track down a process while developing. This
could be a process that's repeatedly crashing, or something that's
misbehaving by using up too many resources. Being able to seamlessly
look at what's happening on the host makes for a better developer
experience.
The toolbox doesn't intend to provide a segregated security domains,
so this is fine.
The "fedora" prefix was used because this project was specifically
incubated to make it easier to hack on Fedora Silverblue. That and the
mix of upstream technologies (ie., Buildah and Podman) made it uniquely
"Fedora".
However, over time it has gotten clear that other groups, currently
Fedora downstreams like RHEL, are interested in it too. It won't be
surprising if in future it transcends the Fedora universe altogether.
Moreover, this project was inspired by coreos/toolbox [1]. There are
good reasons and enough interest to have a unified toolbox project
that addresses the needs of both Fedora CoreOS and Silverblue.
Therefore, it is best to drop the "fedora" prefix and call the whole
thing just "toolbox".
No extra effort was made to retain compatibility with the older name
due to the project's young age. Its userbase is limited to the earliest
of early adopters, and the benefits of a clean break outweigh the
loss of compatibility.
The OCI images and the toolbox container still retain the "fedora"
prefix to disambiguate them from their counterparts from other
operating systems.
[1] https://github.com/coreos/toolboxhttps://github.com/debarshiray/toolbox/issues/8
Using "$0" leads to printing the entire path to the fedora-toolbox
script, which adds visual noise to the output. Command line tools like
GNU Coreutils and Git remove any leading directory components from
the path, which seems like a reasonable trade-off between aesthetics
and verbosity.
https://github.com/debarshiray/fedora-toolbox/pull/50
- OSTree systems aren't fully immutable, you *can* install things
we just discourage it
- fedora-toolbox can (and should!) be used on non-OSTree based
systems as well
https://github.com/debarshiray/fedora-toolbox/pull/43
Simplify the prompt. Most people are going to use the Fedora package.
Hence, the prompt doesn't need to reflect the fedora-toolbox Git tree
as the current directory.
Silverblue, and rpm-ostree more generally are moving to
HOME=/var/home/$USER and make the /home symlink just a compatibility
feature. See:
https://github.com/projectatomic/rpm-ostree/pull/1726
Matching what the host does will reduce weird side-effects. Propagate
$HOME into the container to avoid mismatches in /etc/default/useradd,
and if the host has /home as a symlink to /var/home, do the same for
the toolbox.
https://github.com/debarshiray/fedora-toolbox/pull/34
Currently, the non-root interactive shells were being spawned with a
full set of capabilities. This led to unexpected root-like behaviour
for non-root users. All capability sets, except the Permitted (or
CapBnd) set, should be cleared to match the usual state of a host
interactive shell for non-root users.
It doesn't look like podman offers a way to forward CapBnd from the
host without touching the other sets. If '--privileged' is used with
'podman create', then it forwards CapBnd but also initializes the
others to have a full set of capabilities. If it's not used, then it
doesn't touch anything other than CapBnd, but only forwards a subset
of the host's CapBnd, which means that using sudo to attain elevated
privileges inside the toolbox won't give the full set of capabilities
as on the host.
It might be so that having a smaller CapBnd actually doesn't matter.
However, until that's proven true, it's safer to insist on having
'--privileged' forward the full set, and then clear up the other sets
on our own.
https://github.com/debarshiray/fedora-toolbox/issues/16
If the last command that was run interactively inside the toolbox
container had returned with a non-zero return code, then exiting the
toolbox would trigger the fallback to /bin/bash, just like it would
happen if $SHELL was missing from the toolbox. This is because
'podman exec ...' relays the return code of the last command.
Therefore, don't rely on the return code of 'podman exec ...' and check
the availability of $SHELL upfront. This does leave it vulnerable to
races caused by the availability of $SHELL changing between the check
and the actual attempt to use it. However, file I/O is inherently racy,
and this is better than a spurious fallback.
Keep the name of the default interactive shell localized to 'enter' by
using a subshell because 'local' is not mandated by POSIX.
It bind mounts $DBUS_SYSTEM_BUS_ADDRESS, if present, and sets the
DBUS_SYSTEM_BUS_ADDRESS environment variable inside the toolbox.
Otherwise, it defaults to "unix:path=/var/run/dbus/system_bus_socket"
as defined in the D-Bus specification [1].
[1] https://dbus.freedesktop.org/doc/dbus-specification.html
Rootless podman shuld mount a tmpfs at /dev/shm by default. Until that
happens, it's worked around by explicitly specifying the mount point.
Also, the --shm-size flag isn't working with rootless podman [1], so
--tmpfs is used instead.
It tries to mimic the in-kernel tmpfs default [2] of using half the
amount of total RAM. If for some reason /proc/meminfo can't be parsed,
it falls back to using podman's default of 65536k for tmpfs. It's not
clear whether podman uses kibibytes or kilobytes for 'k'. The former
was picked here for consistency.
[1] https://github.com/containers/libpod/issues/1770
[2] https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txthttps://github.com/debarshiray/fedora-toolbox/issues/9
It's the user's responsibility to install any non-default shell inside
the toolbox container.
NB: /bin/bash is the default shell according to /etc/default/useradd.
