distrobox-host-exec: new tool for host command execution

[dfaggioli]

Executing commands on the host, while inside of a container, can be done
either with flatpak-spawn, of playing tricks with chroot. Let's provide
a new script, which will be available inside of the container, that does
exactly that.

This tries to improve (although maybe not completely fix):
#177

Signed-off-by: Dario Faggioli dfaggioli@suse.com

[dfaggioli]

I think we should also try to install flatpak-spawn automatcally.

I can do that in another patch. Shall we do that at init time, or the first time the user uses distrobox-host-exec?

I kind of like the latter, but it'd mean copying the package handling logic in that script, which is not really nice...

[misobarisic]

Adding a new command requires updating the readme's "What it does" to reflect the addition.

[89luca89]

Hi @dfaggioli thanks!

I'd add a couple of things if possible:

1 - an entry in README.md, as we're adding a new command (and updating the TOC)
2 - I'd add this check in the script, just like in export and init:

distrobox/distrobox-init

Line 144 in 546a569

if [ ! -f /run/.containerenv ] && [ ! -f /.dockerenv ]; then

to ensure we run it only in a container

I'd leave the installation of flatpak-spawn to the user, I'd like to leave the thing as simple as possible

[dfaggioli]

Hey, @misobarisic , @89luca89 ! Pull request updated; I think I've done what you've asked

[89luca89]

@dfaggioli thanks Dario! Left a couple of comments

Testing today the host-exec, I've encountered quite a few problems on the chroot approach sadly
I see that not only you cannot use podman or docker, but you cannot even use sudo

Here are examples:

luca-linux@distrobox:~/Desktop$ ./distrobox-host-exec podman ps
Warning: flatpak-spawn not found! We recommend installing it.
In the meantime, we'll try an alternative (but less powerfull) approach
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
cannot clone: Operation not permitted
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
cannot clone: Operation not permitted
WARN[0000] "/" is not a shared mount, this could cause issues or missing mounts with rootless containers 
cannot clone: Operation not permitted
ERRO[0000] invalid internal status, try resetting the pause process with "podman system migrate": cannot re-exec process 

And for sudo:

luca-linux@distrobox:~/Desktop$ ./distrobox-host-exec bash -l
Warning: flatpak-spawn not found! We recommend installing it.
In the meantime, we'll try an alternative (but less powerfull) approach
[luca-linux@microos Desktop]$ sudo su -
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: /bin/sudo must be owned by uid 0 and have the setuid bit set
[luca-linux@microos Desktop]$ 

This is only for rootless containers, rootful containers don't have the second problem.

In case of rootful containers we could use nsenter to escape the container:

nsenter -t MY_PID -m -u -n -i sh

Where MY_PID is whatever pid from the $USER

This is obviously not possible as a general approach, where flatpak-spawn excels!

So either:

• we found another way to escape the container
• we inform quite more the user of the chroot limitation

[dfaggioli]

So either:
* we found another way to escape the container
* we inform quite more the user of the chroot limitation

Ok... Let me put something together for option 2, and let's see what you think.

[dfaggioli]

So either:

• we found another way to escape the container
• we inform quite more the user of the chroot limitation

Ok... Let me put something together for option 2, and let's see what you think.

So, @89luca89 , how about now?

If you like it, there are those two shellcheck warnings, that I'm not sure I fully understand what they're trying to tell me, and how to make them go away... :-( Any pointer/suggestion would be much appreciated :-)

[89luca89]

So either:

• we found another way to escape the container
• we inform quite more the user of the chroot limitation

Ok... Let me put something together for option 2, and let's see what you think.

So, @89luca89 , how about now?

If you like it, there are those two shellcheck warnings, that I'm not sure I fully understand what they're trying to tell me, and how to make them go away... :-( Any pointer/suggestion would be much appreciated :-)

Yep! Much cleaner that the chroot is really there just in case

For the shellcheck, I've found the problems, I'll comment on the code 👍

[89luca89]

Thanks @dfaggioli LGTM, for now the chroot is explicitly shown as an emergency fallback thanks!

This should Fix #177

Thanks!