Support 'sudo toolbox ...' #267

dustymabe · 2019-09-20T14:46:42Z

One of the use cases from running toolbox on Fedora CoreOS is to debug the system (not development). When running as root I see an error:

[root@coreos ~]# toolbox 
toolbox: /etc/subgid and /etc/subuid don't have entries for user root
See the podman(1), subgid(5), subuid(5) and usermod(8) manuals for more
information.
[root@coreos ~]# exit
logout
[core@coreos ~]$ sudo toolbox
toolbox: /etc/subgid and /etc/subuid don't have entries for user root
See the podman(1), subgid(5), subuid(5) and usermod(8) manuals for more
information.
[core@coreos ~]$

Is this expected?

The text was updated successfully, but these errors were encountered:

cgwalters · 2019-09-20T14:48:07Z

This works with https://github.com/cgwalters/coretoolbox

dustymabe · 2019-09-20T14:50:26Z

This works with https://github.com/cgwalters/coretoolbox

Considering we decided that we don't want to have two implementations and that we'll work together on toolbox I don't believe that's a helpful reminder.

cgwalters · 2019-09-20T14:51:17Z

Considering we decided that we don't want to have two implementations and that we'll work together on toolbox I don't believe that's a helpful reminder.

Where was that decided?

dustymabe · 2019-09-20T15:20:26Z

Well it seems like we've discussed "toolbox" a lot. In coreos/fedora-coreos-tracker#38 and https://github.com/debarshiray/toolbox/issues/8 and coreos/fedora-coreos-tracker#90. @mike-nguyen and @yuqi-zhang have been working together with @debarshiray IIUC to align the efforts. We have not added it to our design document so I guess we are missing a formal agreement, but in the meeting a week ago I didn't hear anyone dissenting on including toolbox once the deps were aligned. Outside of the meeting you spoke up and we tried to address the concerns you had in the next meeting. I thought we had addressed those concerns.

cgwalters · 2019-09-20T15:23:58Z

but in the meeting a week ago I didn't hear anyone dissenting on including toolbox once the deps were aligned.

I dissent until we have resolved the discussion in https://github.com/debarshiray/toolbox/issues/265

Toolbox might be used as root or rootless. Including the real user ID in the debug output can help understand bugs or oddities caused by differences in root versus rootless scenarios. https://github.com/debarshiray/toolbox/issues/267

The /etc/subgid and /etc/subuid files are only meant to be used when running rootless, and hence don't have an entry for root. https://github.com/debarshiray/toolbox/issues/267

debarshiray · 2019-09-23T16:32:24Z

When running as root I see an error:

[root@coreos ~]# toolbox 
toolbox: /etc/subgid and /etc/subuid don't have entries for user root
See the podman(1), subgid(5), subuid(5) and usermod(8) manuals for more
information.
[root@coreos ~]# exit
logout
[core@coreos ~]$ sudo toolbox
toolbox: /etc/subgid and /etc/subuid don't have entries for user root
See the podman(1), subgid(5), subuid(5) and usermod(8) manuals for more
information.
[core@coreos ~]$

Is this expected?

That's caused by an explicit sanity check in Toolbox to ensure that people have sane /etc/subuid and /etc/subgid files, which are crucial for rootless Podman. It's meant for users who tend to upgrade across major OS releases and might have created their local user account with an old version of shadow-utils that didn't update those files. An upfront human readable error is better than weird rootless Podman failures later in the process.

Clearly this check needs to be skipped when running as root. :)

I can imagine a few more things that might cause problems when running as root. eg., $XDG_RUNTIME_DIR might be unset, no user or session D-Bus to talk to the Flatpak session helper to monitor configuration files that need to be kept synchronized, and need to skip useradd in toolbox init-container.

debarshiray · 2019-09-23T16:35:34Z

https://github.com/debarshiray/toolbox/pull/273 solves this specific issue, but we still need to work through the other differences between root and rootless scenarios.

dustymabe · 2019-09-25T14:44:18Z

I can imagine a few more things that might cause problems when running as root. eg., $XDG_RUNTIME_DIR might be unset

You were right! I now hit this:

mkdir: cannot create directory '/toolbox': Operation not permitted

because of toolbox_runtime_directory="$XDG_RUNTIME_DIR"/toolbox

HarryMichal · 2019-09-26T10:36:00Z

Just found an old issue from Podman where they were solving this kind of problem: containers/podman#427. Their solution was to create /run/containers instead of /run/user/UID/containers.

dustymabe · 2019-10-16T19:08:21Z

Workaround:

[root@coreos ~]# export XDG_RUNTIME_DIR=/opt/                                                                          
[root@coreos ~]# toolbox -v enter

dustymabe · 2019-10-16T19:09:28Z

Next issue:

[root@coreos ~]# export XDG_RUNTIME_DIR=/opt/
[root@coreos ~]# toolbox -v enter
toolbox: running as real user ID 0
toolbox: resolved absolute path for /usr/bin/toolbox to /usr/bin/toolbox
toolbox: TOOLBOX_PATH is /usr/bin/toolbox
toolbox: Fedora generational core is f30
toolbox: base image is fedora-toolbox:30
toolbox: container is fedora-toolbox-30
toolbox: checking if container fedora-toolbox-30 exists
toolbox: container fedora-toolbox-30 not found
toolbox: found 0 containers
No toolbox containers found. Create now? [y/N] y
toolbox: Fedora generational core is f30
toolbox: base image is fedora-toolbox:30
toolbox: container is fedora-toolbox-30
toolbox: failed to read property Listen from sssd-kcm.socket
toolbox: parsing value  of property Listen in sssd-kcm.socket
toolbox: checking if 'podman create' supports --ulimit host
/usr/bin/toolbox: line 758: man: command not found
toolbox: looking for image localhost/fedora-toolbox:30
toolbox: looking for image registry.fedoraproject.org/f30/fedora-toolbox:30
Image required to create toolbox container.
Download registry.fedoraproject.org/f30/fedora-toolbox:30 (500MB)? [y/N]: y
toolbox: pulling image registry.fedoraproject.org/f30/fedora-toolbox:30
Trying to pull registry.fedoraproject.org/f30/fedora-toolbox:30...
Getting image source signatures
Copying blob 5eb34e12d23e done
Copying blob b2b686c4a538 done
Copying config 06478f0b37 done
Writing manifest to image destination
Storing signatures
toolbox: base image fedora-toolbox:30 resolved to registry.fedoraproject.org/f30/fedora-toolbox:30
toolbox: checking if container fedora-toolbox-30 already exists
toolbox: checking if /usr is mounted read-only or read-write
toolbox: mount-point of /usr is /usr
toolbox: mount flags of /usr on the host are ro,relatime,seclabel,attr2,inode64,prjquota
toolbox: /root canonicalized to /var/roothome
toolbox: checking if /home is a symbolic link to /var/home
toolbox: /home is a symbolic link to /var/home
toolbox: calling org.freedesktop.Flatpak.SessionHelper.RequestSession
Error connecting: Cannot autolaunch D-Bus without X11 $DISPLAY
toolbox: failed to call org.freedesktop.Flatpak.SessionHelper.RequestSession

so we'd need to figure out how to launch dbus without X11 $DISPLAY variable

jamescassell · 2020-01-21T11:41:20Z

I ran into this today. It makes Fedora CoreOS much more difficult to use because if you need to operate on the host, you have to either rpm-ostree install or use podman directly.

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 o.fd.Flatpak.SessionHelper. containers#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 o.fd.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. containers#267

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#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 o.fd.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. containers#267

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#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. containers#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. containers#267

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

A subsequent will need to inspect the container to know whether it needs the org.freedesktop.Flatpak.SessionHelper D-Bus service to be running. Since the container is already being inspected to get its entry point, the same JSON can be used for this. containers#267

... 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. containers#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. containers#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. containers#267

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

... 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. containers#267

containers#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. containers#267

containers#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. containers#267

A subsequent commit will add another argument to the OSC 777 escape sequence to specify the user ID that toolbox(1) is running as. Unlike the NAME and RUNTIME arguments, the UID argument won't be optional when popping. Therefore it's nicer to spell everything out for the sake of completeness. This shouldn't cause any user-visible change. containers#267

This is one more step towards enabling toolbox(1) to be run as root. When invoked as 'sudo toolbox enter', GNOME Terminal might choose not to preserve the current toolbox container when opening a new terminal. This is similar to how the current working directory of a 'su -' session isn't preserved when opening a new terminal. containers#267

A subsequent commit will add another argument to the OSC 777 escape sequence to specify the user ID that toolbox(1) is running as. Unlike the NAME and RUNTIME arguments, the UID argument won't be optional when popping. Therefore it's nicer to spell everything out for the sake of completeness. This change relies on VTE reading in all the remaining arguments when popping. Otherwise, the argument(s) might get spuriously displayed in the terminal. containers#267

This is one more step towards enabling toolbox(1) to be run as root. When invoked as 'sudo toolbox enter', GNOME Terminal might choose not to preserve the current toolbox container when opening a new terminal. This is similar to how the current working directory of a 'su -' session isn't preserved when opening a new terminal. containers#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. containers#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. containers#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. containers#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. containers#267

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. containers#267

debarshiray · 2020-12-18T15:50:28Z

I think this can be closed now. Any follow-up issues with sudo toolbox can be tracked in separate issues.

debarshiray mentioned this issue Sep 23, 2019

Don't sanity check /etc/subgid and /etc/subuid when running as root #273

Merged

dustymabe mentioned this issue Oct 16, 2019

fedora-coreos-base: add in toolbox coreos/fedora-coreos-config#201

Merged

HarryMichal added 1. Bug Something isn't working 5. Help Wanted Extra attention is needed labels Nov 7, 2019

jlebon mentioned this issue Feb 5, 2020

merge of fedora-toolbox and coreos-toolbox efforts coreos/fedora-coreos-tracker#90

Open

debarshiray changed the title ~~running toolbox as root gives subgid subuid error~~ Support 'sudo toolbox ...' Oct 22, 2020

debarshiray mentioned this issue Oct 22, 2020

cmd/initContainer: Don't rely on user D-Bus to track time zone configuration #591

Merged

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 23, 2020

Don't set up the org.freedesktop.Flatpak.SessionHelper D-Bus service

b4d1bd8

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 23, 2020

cmd/create: Don't set up org.freedesktop.Flatpak.SessionHelper

ed1b46f

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 23, 2020

cmd/create: Don't set up org.freedesktop.Flatpak.SessionHelper

228662e

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 26, 2020

cmd/create: Don't set up org.freedesktop.Flatpak.SessionHelper

71b5c8c

It's no longer used to keep /etc/localtime and /etc/timezone synchronized with the host. containers#267

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 27, 2020

Don't rely on XDG_RUNTIME_DIR when running as root

66b066a

containers#267

debarshiray mentioned this issue Oct 27, 2020

Don't rely on XDG_RUNTIME_DIR when running as root #599

Merged

debarshiray added a commit to debarshiray/toolbox that referenced this issue Oct 27, 2020

Don't rely on XDG_RUNTIME_DIR when running as root

c90883c

containers#267

debarshiray mentioned this issue Oct 29, 2020

cmd/run: Pass the UID when notifying the terminal about the container #607

Closed

debarshiray closed this as completed Dec 18, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support 'sudo toolbox ...' #267

Support 'sudo toolbox ...' #267

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

debarshiray commented Sep 23, 2019

debarshiray commented Sep 23, 2019

dustymabe commented Sep 25, 2019

HarryMichal commented Sep 26, 2019

dustymabe commented Oct 16, 2019

dustymabe commented Oct 16, 2019

jamescassell commented Jan 21, 2020

debarshiray commented Dec 18, 2020

Support 'sudo toolbox ...' #267

Support 'sudo toolbox ...' #267

Comments

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

dustymabe commented Sep 20, 2019

cgwalters commented Sep 20, 2019

debarshiray commented Sep 23, 2019

debarshiray commented Sep 23, 2019

dustymabe commented Sep 25, 2019

HarryMichal commented Sep 26, 2019

dustymabe commented Oct 16, 2019

dustymabe commented Oct 16, 2019

jamescassell commented Jan 21, 2020

debarshiray commented Dec 18, 2020