search

89luca89 / distrobox

Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
https://distrobox.it/
GNU General Public License v3.0
10.09k stars 416 forks source link

[Error] sudo permissions change in rootless container #825

Closed UriHerrera closed 1 year ago

UriHerrera commented 1 year ago

Describe the bug After creating a rootless Debian container (I haven't tested using other containers), sudo becomes inaccessible seemingly after a random amount of time.

I was under the impression that creating a rootful container using the same name as a rootless container would cause the problem, but that's not the case.

To Reproduce I can't find a way to reproduce the problem other than creating the container, using it, exiting it, and repeating it.

Eventually, sudo can't be used anymore.

sudo: /etc/sudo.conf is owned by uid 1001, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

Expected behavior sudo can be used.

Logs https://gist.github.com/UriHerrera/dd9c6fecd75c60579094acd9336cb745

Desktop (please complete the following information):

Additional context The Easiest way around the problem is to create the container again. However, the problem is persistent.

rrahl0 commented 1 year ago

we definitely need more info like Host OS, logs from creating the container, what you actually do in the debian container.

and for some reason this error sudo: /etc/sudo.conf is owned by uid 1001, should be 0 screams to me that something in the setup errors out (as all distrobox containers are privileged which means UID=0 is outside UID=$user (normally 1000).

UriHerrera commented 1 year ago

Here's the log when I create the container: https://gist.github.com/UriHerrera/f2eeb7f5733d01a1bddc50d7f7b48b44 Here's command history after I've created the container:

 5711  distrobox create -n sid-rootless -i debian:sid -v
 5712  distrobox enter sid-rootless
 5713  groups uri
 5714  gid
 5715  id -u uri
 5716  id -ug uri
 5717  id 0g uri
 5718  clear
 5719  id uri
 5720  clear
 5721  sudo apt update
 5722  sudo apt install micro locales --no-install-recommends -y
 5723  sudo dpkg-reconfigure locales
 5724  clear
 5725  sudo rm /etc/apt/sources.list.d/debian.sources
 5726  sudo micro /etc/apt/sources.list
 5727  distrobox enter sid-rootless
 5728* history
 5729* sudo micro /etc/apt/preferences.d/tzdata
 5730* sudo apt updgrade
 5731* sudo apt upgrade
 5732* sudo apt update
 5733* apt-cache policy
 5734* sudo micro /etc/apt/preferences.d/tzdata
 5735* sudo micro /etc/apt/sources.list
 5736* sudo apt update
 5737* sudo apt upgrade
 5738* clear
 5739* exit

Host is Nitrux.

rrahl0 commented 1 year ago

can you verify on your Host that your UID is 1001 and GID 1003? As I don't know Nitrux, idk if that is default/normal.

otherwise your logs seem fine. And I can't replicate this.

UriHerrera commented 1 year ago

Indeed, the UID for my user is 1001, and the GID is 1003.

imagen

I've noticed that when I first created the container, the file /etc/sudo.conf was owned by root, but now it's owned by my user.

rrahl0 commented 1 year ago

can't really help, as it doesn't happen on my machines (debian 12, openSUSE Tumbleweed/Aeon)

$ distrobox ephemeral --image docker.io/debian:sid --additional-packages bash-completion
Trying to pull docker.io/library/debian:sid...
Getting image source signatures
Copying blob 2e79cba44192 done  
Copying config 4b2de9ef18 done  
Writing manifest to image destination
Storing signatures
4b2de9ef18b380e95f957d9bbb1d4b0b5ba83cf9c94ad4a0d3a1815e89bcef9c
Creating 'distrobox-ArxZ3hrlyT' using image docker.io/debian:sid     [ OK ]
Distrobox 'distrobox-ArxZ3hrlyT' successfully created.
To enter, run:

distrobox enter distrobox-ArxZ3hrlyT

Container distrobox-ArxZ3hrlyT is not running.
Starting container distrobox-ArxZ3hrlyT
run this command to follow along:

 podman logs -f distrobox-ArxZ3hrlyT

 Starting container...                       [ OK ]
 Executing pre-init hooks...                 [ OK ]
 Installing basic packages...                [ OK ]
 Setting up read-only mounts...              [ OK ]
 Setting up read-write mounts...             [ OK ]
 Setting up host's sockets integration...    [ OK ]
 Integrating host's themes, icons, fonts...  [ OK ]
 Setting up package manager exceptions...    [ OK ]
 Setting up dpkg exceptions...               [ OK ]
 Setting up apt hooks...                     [ OK ]
 Setting up sudo...                          [ OK ]
 Setting up groups...                        [ OK ]
 Setting up users...                         [ OK ]
 Executing init hooks...                     [ OK ]

Container Setup Complete!
user@distrobox-ArxZ3hrlyT:~$ sudo
usage: sudo -h | -K | -k | -V
usage: sudo -v [-ABkNnS] [-g group] [-h host] [-p prompt] [-u user]
usage: sudo -l [-ABkNnS] [-g group] [-h host] [-p prompt] [-U user] [-u user]
            [command [arg ...]]
usage: sudo [-ABbEHkNnPS] [-r role] [-t type] [-C num] [-D directory] [-g
            group] [-h host] [-p prompt] [-R directory] [-T timeout] [-u user]
            [VAR=value] [-i | -s] [command [arg ...]]
usage: sudo -e [-ABkNnS] [-r role] [-t type] [-C num] [-D directory] [-g group]
            [-h host] [-p prompt] [-R directory] [-T timeout] [-u user] file ...
user@distrobox-ArxZ3hrlyT:~$ ls -l /etc/sudo.conf 
-rw-r--r-- 1 root root 4343 Jun 27 11:43 /etc/sudo.conf
UriHerrera commented 1 year ago

I can't reproduce this anymore. So, I was upgrading the distribution as indicated here. Delete the old root and create a new one. I figured that had something to do with the error. As I understood, whenever the installer creates a new user account, if it's the first user account and the username and password are the same, it's always the same UID and GID when the installer creates it on the new installation. So, I'd do that as I had no problem restoring files (because of the ownership), but this problem with sudo in the containers was constant.

During the latest update to Distrobox, I noticed it now requires CGroups v2. I updated the OpenRC configuration of Nitrux to CGroups v2. Then I created a container and did the same procedure, except that this problem with sudo is no longer present.

I suppose that was the problem.

cdock1029 commented 7 months ago

I'm having this issue on openSUSE Aeon, and currently I can't create any new distrobox without the problem occurring immediately from first boot:

cdock@localhost:~> distrobox enter
Error: no such container tumbleweed
Creating the container tumbleweed
Creating 'tumbleweed' using image registry.opensuse.org/opensuse/distrobox:latest    [ OK ]
Distrobox 'tumbleweed' successfully created.
To enter, run:

distrobox enter tumbleweed

Starting container...                        [ OK ]
Installing basic packages...                 [ OK ]
Setting up devpts mounts...                  [ OK ]
Setting up read-only mounts...               [ OK ]
Setting up read-write mounts...              [ OK ]
Setting up host's sockets integration...     [ OK ]
Integrating host's themes, icons, fonts...   [ OK ]
Setting up package manager exceptions...     [ OK ]
Setting up rpm exceptions...                 [ OK ]
Setting up distrobox profile...              [ OK ]
Setting up sudo...                           [ OK ]
Setting up user groups...                    [ OK ]
Setting up kerberos integration...           [ OK ]
Setting up user's group list...              [ OK ]
Setting up existing user...                  [ OK ]
Setting up user home...                      [ OK ]
Ensuring user's access...                    [ OK ]

Container Setup Complete!
cdock@tumbleweed:~> sudo zypper ref
sudo: /usr/etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
cdock@tumbleweed:~>
cdock@tumbleweed:~> cd /
cdock@tumbleweed:/> l
total 16
dr-xr-xr-x.   1 root   root     32 Mar 19 23:25 ./
dr-xr-xr-x.   1 root   root     32 Mar 19 23:25 ../
lrwxrwxrwx.   1 cdock  cdock     7 Feb  2 11:16 bin -> usr/bin/
dr-xr-xr-x.   1 cdock  cdock     0 Mar 17 20:17 boot/
drwxr-xr-x.  19 nobody nobody 4340 Mar 19 23:23 dev/
drwxr-xr-x.   1 cdock  cdock   224 Mar 19 23:25 etc/
dr-xr-xr-x.   1 cdock  cdock    10 Mar 19 23:25 home/
lrwxrwxrwx.   1 cdock  cdock     7 Feb  2 11:16 lib -> usr/lib/
lrwxrwxrwx.   1 cdock  cdock     9 Feb  2 11:16 lib64 -> usr/lib64/
dr-xr-xr-x.   1 nobody nobody    0 Mar 18 16:11 mnt/
dr-xr-xr-x.   1 cdock  cdock     0 Mar 17 20:17 opt/
dr-xr-xr-x. 466 nobody nobody    0 Mar 19 19:23 proc/
drwx------.   1 cdock  cdock    18 Mar 17 20:17 root/
drwxr-xr-x.   1 cdock  cdock   158 Mar 19 23:25 run/
lrwxrwxrwx.   1 cdock  cdock     8 Feb  2 11:16 sbin -> usr/sbin/
dr-xr-xr-x.   1 cdock  cdock     6 Mar 17 20:17 srv/
dr-xr-xr-x.  13 nobody nobody    0 Mar 19 23:23 sys/
drwxrwxrwt.  16 nobody nobody  460 Mar 19 23:25 tmp/
drwxr-xr-x.   1 cdock  cdock    22 Mar 17 20:17 usr/
drwxr-xr-x.   1 cdock  cdock     6 Mar 17 20:17 var/
cdock@tumbleweed:/> 
cdock@tumbleweed:/> exit
logout
cdock@localhost:~> id cdock
uid=1000(cdock) gid=1000(cdock) groups=1000(cdock),480(wheel)
cdock1029 commented 7 months ago

I removed all containers, images, and did podman system reset and it's working, for now. Not really sure what I did to cause it. Just installed Aeon yesterday for the first time, so this is after 1 day of usage.

Only things I can think of: I observed this failure shortly after I created a clone of an Ubuntu container with --clone flag, then sometime after the base Ubuntu container exhibited this problem. Eventually it happened in the tumbleweed container, then any subsequent one.

What I also did, and I can't remember if this was before or after making the clone, was I thought you could enter rootless containers as root by passing the --root flag having misunderstood the documentation.

So I ran: distrobox enter ubuntu --root and I noticed it was starting to create a new distrobox so I Ctrl-C cancelled right away. Not sure if this would have corrupted something.

findurance commented 3 months ago

I removed all containers, images, and did podman system reset and it's working, for now

I had the same issue, for some reason Podman altered the permissions. As a side note, podman system reset does all those things: deletes containers and stuff. But this fixed it. Just need to get containers backed up regularly, maybe...

So I ran: distrobox enter ubuntu --root and I noticed it was starting to create a new distrobox

I did something similar, actually, but without the --root flag. In openSUSE a new default "tumbleweed" container was started to get created with a same name 'focal', which I was supposed to have for another container.

After that I also tried creating a "tumbleweed" container with just the default settings, using distrobox create and distrobox enter tumbleweed. And there were same permission issues with sudo executable.