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.
The base fedora-toolbox images for Fedoras 28, 29 and 30 are now
available from registry.fedoraproject.org. Hence it's no longer
mandatory to build them locally. If they are built locally, then the
local images will be preferred over the ones from the registry.
https://pagure.io/releng/issue/7874
Hard coding 'fedora-toolbox' instead of $0 was necessary to get a
pleasant layout while keeping the code simple. It's not a big deal
because once there's a build system in place most people will type
'fedora-toolbox', instead of the full path to the script.
