Distrobox images not allowing 'sudo' to be used
We've got a forum user using Distrobox with an arch image who is getting an error that '<username> is not in sudoers' file. I found a thread a couple months ago on Reddit reporting this as well, and it seemed to be thought that this was likely an issue with the arch image. But I'm trying this with Tumbleweed as well (both as 'host' and 'guest'), and sudo is prompting for the root password, but isn't accepting it. I've tried just about everything I can think of for a password, and it's simply not accepting anything that would be valid on this system. I had been able to run sudo within distrobox previously (used it to install software with zypper, for example) - but I had been using an older image that I since have gotten rid of for the current one. Creating the container with '--absolutely-disable-root-password-i-am- really-positively-sure' lets sudo work, but is not a secure workaround. I'm wondering if this could be related to config files moving to /usr/etc from /etc. Any tips on how to troubleshoot would be appreciated. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Mon, 22 Jan 2024 22:48:12 -0000 (UTC), Jim Henderson wrote:
We've got a forum user using Distrobox with an arch image who is getting an error that '<username> is not in sudoers' file. I found a thread a couple months ago on Reddit reporting this as well, and it seemed to be thought that this was likely an issue with the arch image.
The user has worked around it by adding himself to 'wheel' in the host, but that didn't used to be necessary, so I'm still curious as to how to get the original functionality back. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Hi, I don't think this is possible in 1.6.0, see the default sudoers config created by distrobox: https://github.com/89luca89/distrobox/blob/main/distrobox-init#L1779 distrobox-init assigns the wheels/sudo/root groups to the user in guest container if host user has them. Maybe mounting a volume with one's own sudoers into the container will work as well. On Mon, Jan 22, 2024 at 11:55 PM Jim Henderson <hendersj@gmail.com> wrote:
On Mon, 22 Jan 2024 22:48:12 -0000 (UTC), Jim Henderson wrote:
We've got a forum user using Distrobox with an arch image who is getting an error that '<username> is not in sudoers' file. I found a thread a couple months ago on Reddit reporting this as well, and it seemed to be thought that this was likely an issue with the arch image.
The user has worked around it by adding himself to 'wheel' in the host, but that didn't used to be necessary, so I'm still curious as to how to get the original functionality back.
-- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On Tue, 23 Jan 2024 13:09:28 +0100, Michal Vyskocil wrote:
I don't think this is possible in 1.6.0, see the default sudoers config created by distrobox: https://github.com/89luca89/distrobox/blob/main/distrobox-init#L1779 distrobox-init assigns the wheels/sudo/root groups to the user in guest container if host user has them.
Maybe mounting a volume with one's own sudoers into the container will work as well.
The thing that I find strange is that if I create the container with the option to leave the root password blank, I can see the sudoers file includes the files in /etc/sudoers.d/ - which includes a configuration that includes "jhenderson" (my username, in quotes), but it varies slightly from the way my host is set up. In the arch distrobox, it's included from /etc/sudoers; in the TW distrobox, it's included from /usr/etc/sudoers I tested on my host modifying the sudoers file to put my username in quotes, and that still worked, so it seems like it should be working. The line in /etc/sudoers.d/sudoers in the containers is: "jhenderson" ALL = (root) NOPASSWD:ALL (Yes, I use NOPASSWD; yes, I understand the risks.) On the host, (root) is instead (ALL) - but as that's just defining the user(s) that I can sudo as, that shouldn't be an issue. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
On 23.01.2024 20:15, Jim Henderson wrote:
On Tue, 23 Jan 2024 13:09:28 +0100, Michal Vyskocil wrote:
I don't think this is possible in 1.6.0, see the default sudoers config created by distrobox: https://github.com/89luca89/distrobox/blob/main/distrobox-init#L1779 distrobox-init assigns the wheels/sudo/root groups to the user in guest container if host user has them.
Maybe mounting a volume with one's own sudoers into the container will work as well.
The thing that I find strange is that if I create the container with the option to leave the root password blank, I can see the sudoers file includes the files in /etc/sudoers.d/ - which includes a configuration that includes "jhenderson" (my username, in quotes), but it varies slightly from the way my host is set up.
In the arch distrobox, it's included from /etc/sudoers; in the TW distrobox, it's included from /usr/etc/sudoers
I tested on my host modifying the sudoers file to put my username in quotes, and that still worked, so it seems like it should be working.
The line in /etc/sudoers.d/sudoers in the containers is:
"jhenderson" ALL = (root) NOPASSWD:ALL
(Yes, I use NOPASSWD; yes, I understand the risks.)
On the host, (root) is instead (ALL) - but as that's just defining the user(s) that I can sudo as, that shouldn't be an issue.
Are you talking about https://github.com/89luca89/distrobox/issues/1092? Then it is clear - distrobox attempts to disable "Default targetpw" in /etc/sudoers, but Tumbleweed/MicroOS have it in /usr/etc/sudoers. It will also fail in every distribution which is using /etc/sudoers.d instead of the main file.
On 23.01.2024 20:39, Andrei Borzenkov wrote:
On 23.01.2024 20:15, Jim Henderson wrote:
On Tue, 23 Jan 2024 13:09:28 +0100, Michal Vyskocil wrote:
I don't think this is possible in 1.6.0, see the default sudoers config created by distrobox: https://github.com/89luca89/distrobox/blob/main/distrobox-init#L1779 distrobox-init assigns the wheels/sudo/root groups to the user in guest container if host user has them.
Maybe mounting a volume with one's own sudoers into the container will work as well.
The thing that I find strange is that if I create the container with the option to leave the root password blank, I can see the sudoers file includes the files in /etc/sudoers.d/ - which includes a configuration that includes "jhenderson" (my username, in quotes), but it varies slightly from the way my host is set up.
In the arch distrobox, it's included from /etc/sudoers; in the TW distrobox, it's included from /usr/etc/sudoers
I tested on my host modifying the sudoers file to put my username in quotes, and that still worked, so it seems like it should be working.
The line in /etc/sudoers.d/sudoers in the containers is:
"jhenderson" ALL = (root) NOPASSWD:ALL
(Yes, I use NOPASSWD; yes, I understand the risks.)
On the host, (root) is instead (ALL) - but as that's just defining the user(s) that I can sudo as, that shouldn't be an issue.
Are you talking about https://github.com/89luca89/distrobox/issues/1092? Then it is clear - distrobox attempts to disable "Default targetpw" in /etc/sudoers, but Tumbleweed/MicroOS have it in /usr/etc/sudoers.
It will also fail in every distribution which is using /etc/sudoers.d instead of the main file.
Yes, it is exactly that. Just do docker -it exec <container> bash echo 'Defaults !targetpw' > /etc/sudoers.d/targetpw or use visudo if your container includes vi.
On Tue, 23 Jan 2024 21:16:42 +0300, Andrei Borzenkov wrote:
Are you talking about https://github.com/89luca89/distrobox/issues/1092? Then it is clear - distrobox attempts to disable "Default targetpw" in /etc/sudoers, but Tumbleweed/MicroOS have it in /usr/etc/sudoers.
It will also fail in every distribution which is using /etc/sudoers.d instead of the main file.
Yes, it is exactly that. Just do
docker -it exec <container> bash echo 'Defaults !targetpw' > /etc/sudoers.d/targetpw
or use visudo if your container includes vi.
Excellent, thanks for this - that does solve the issue for me here. I've updated the thread in the forums (probably tagged you as well in mentioning this thread on the ML). I don't know why it didn't occur to me to use 'docker exec' to inspect the container more closely. That's a good trick that I'll add to my toolbox. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
HI Jim, On Mon, Jan 22, 2024, 5:48 PM Jim Henderson <hendersj@gmail.com> wrote:
We've got a forum user using Distrobox with an arch image who is getting an error that '<username> is not in sudoers' file. I found a thread a couple months ago on Reddit reporting this as well, and it seemed to be thought that this was likely an issue with the arch image.
But I'm trying this with Tumbleweed as well (both as 'host' and 'guest'), and sudo is prompting for the root password, but isn't accepting it. I've tried just about everything I can think of for a password, and it's simply not accepting anything that would be valid on this system.
I had been able to run sudo within distrobox previously (used it to install software with zypper, for example) - but I had been using an older image that I since have gotten rid of for the current one.
Creating the container with '--absolutely-disable-root-password-i-am- really-positively-sure' lets sudo work, but is not a secure workaround.
I'm wondering if this could be related to config files moving to /usr/etc from /etc.
Any tips on how to troubleshoot would be appreciated. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits
Some time ago, I discovered that mounting /var/lib/flatpak with nosuid and nodev broke toolbox in unexpected ways. I reported it and others confirmed it, but there has been no movement to my knowledge. Perhaps, something similar is happening here, but with distrobox and some other directory. -- Tony
participants (4)
-
Andrei Borzenkov -
Jim Henderson -
Michal Vyskocil -
Tony Walker