[Error] Username is not in the sudoers file.

[termdisc]

Describe the bug Newly created distrobox containers are not allowing commands to be run via sudo

To Reproduce

$ distrobox create -n jughead -i archlinux:latest
$ distrobox enter jughead
$ sudo pacman -S git
outphase is not in the sudoers file.

Expected behavior It is expected that pacman installs git without a password prompt.

Logs distrobox-create.txt Podman log

Desktop (please complete the following information):

• Are you using podman or docker? podman
• Which version or podman or docker? 4.6.0
• Which version of distrobox? git

Additional context Creating a container with --root will allow sudo to run as normal, but this would then list the container only when running distrobox list --root i.e., distrobox create --root -n jughead -i archlinux:latest

[89luca89]

Hi @outphase

can you try with latest git version? It works bot with and without --root for me

[termdisc]

I'm still getting the same error with the non-root execution.

distrobox-create.txt distrobox-enter.txt

Here are my passwd and sudoers in case that may lead to anything helpful. I should note that I am also running Bazzite-GNOME, which is similar to or based on Fedora Silverblue.

/etc/passwd

root:x:0:0:root:/root:/bin/bash
outphase:x:1000:1000:NAME:/home/outphase:/usr/bin/fish

/etc/sudoers

## Sudoers allows particular users to run various commands as
## the root user, without needing the root password.
##
## Examples are provided at the bottom of the file for collections
## of related commands, which can then be delegated out to particular
## users or groups.
## 
## This file must be edited with the 'visudo' command.

## Host Aliases
## Groups of machines. You may prefer to use hostnames (perhaps using 
## wildcards for entire domains) or IP addresses instead.
# Host_Alias     FILESERVERS = fs1, fs2
# Host_Alias     MAILSERVERS = smtp, smtp2

## User Aliases
## These aren't often necessary, as you can use regular groups
## (ie, from files, LDAP, NIS, etc) in this file - just use %groupname 
## rather than USERALIAS
# User_Alias ADMINS = jsmith, mikem

## Command Aliases
## These are groups of related commands...

## Networking
# Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool

## Installation and management of software
# Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum

## Services
# Cmnd_Alias SERVICES = /sbin/service, /sbin/chkconfig, /usr/bin/systemctl start, /usr/bin/systemctl stop, /usr/bin/systemctl reload, /usr/bin/systemctl restart, /usr/bin/systemctl status, /usr/bin/systemctl enable, /usr/bin/systemctl disable

## Updating the locate database
# Cmnd_Alias LOCATE = /usr/bin/updatedb

## Storage
# Cmnd_Alias STORAGE = /sbin/fdisk, /sbin/sfdisk, /sbin/parted, /sbin/partprobe, /bin/mount, /bin/umount

## Delegating permissions
# Cmnd_Alias DELEGATING = /usr/sbin/visudo, /bin/chown, /bin/chmod, /bin/chgrp 

## Processes
# Cmnd_Alias PROCESSES = /bin/nice, /bin/kill, /usr/bin/kill, /usr/bin/killall

## Drivers
# Cmnd_Alias DRIVERS = /sbin/modprobe

# Defaults specification

#
# Refuse to run if unable to disable echo on the tty.
#
Defaults   !visiblepw

#
# Preserving HOME has security implications since many programs
# use it when searching for configuration files. Note that HOME
# is already set when the the env_reset option is enabled, so
# this option is only effective for configurations where either
# env_reset is disabled or HOME is present in the env_keep list.
#
Defaults    always_set_home
Defaults    match_group_by_gid

# Prior to version 1.8.15, groups listed in sudoers that were not
# found in the system group database were passed to the group
# plugin, if any. Starting with 1.8.15, only groups of the form
# %:group are resolved via the group plugin by default.
# We enable always_query_group_plugin to restore old behavior.
# Disable this option for new behavior.
Defaults    always_query_group_plugin

Defaults    env_reset
Defaults    env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS"
Defaults    env_keep += "MAIL QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults    env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults    env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults    env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"

#
# Adding HOME to env_keep may enable a user to run unrestricted
# commands via sudo.
#
# Defaults   env_keep += "HOME"

Defaults    secure_path = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin

## Next comes the main part: which users can run what software on 
## which machines (the sudoers file can be shared between multiple
## systems).
## Syntax:
##
##  user    MACHINE=COMMANDS
##
## The COMMANDS section may have other options added to it.
##
## Allow root to run any commands anywhere 
root    ALL=(ALL)   ALL

## Allows members of the 'sys' group to run networking, software, 
## service management apps and more.
# %sys ALL = NETWORKING, SOFTWARE, SERVICES, STORAGE, DELEGATING, PROCESSES, LOCATE, DRIVERS

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)   ALL

## Same thing without a password
# %wheel    ALL=(ALL)   NOPASSWD: ALL

## Allows members of the users group to mount and unmount the 
## cdrom as root
# %users  ALL=/sbin/mount /mnt/cdrom, /sbin/umount /mnt/cdrom

## Allows members of the users group to shutdown this system
# %users  localhost=/sbin/shutdown -h now

## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d

[termdisc]

Further details that may be relevant:

I am running fish on the host which is supposed to be propagated down to the box. I used lchsh to reset to bash, and I now get the following output:

$ ./distrobox enter archie
Container archie is not running.
Starting container archie
run this command to follow along:

 podman logs -f archie

 Starting container...                       [ 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 pacman exceptions...             [ OK ]
 Setting up pacman hooks...                  [ OK ]
 Integrating host's themes, icons, fonts...  [ OK ]
 Setting up package manager exceptions...    [ OK ]
 Setting up pacman exceptions...             [ OK ]
 Setting up pacman hooks...                  [ OK ]
 Setting up sudo...                          [ OK ]
 Setting up groups...                        [ OK ]
 Setting up users...                         [ OK ]
 Setting up sudo...                          [ OK ]
 Setting up groups...                        [ OK ]
 Setting up users...                         [ OK ]
 Executing init hooks...                     [ OK ]

Container Setup Complete!
⚠️  First time user password setup ⚠️ 
New password: 
Retype new password: 
passwd: password updated successfully
📦[outphase@archibald distrobox]$ sudo pacman -S git

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

For security reasons, the password you type will not be visible.

[sudo] password for outphase: 
outphase is not in the sudoers file.

Notably, I did not get the first time user password setup when I was using fish as my shell, but in the end I am still not part of the sudoers.

It has also come to my attention that I had been using git, not 1.5.0.2 as originally stated.

[89luca89]

Sadly I cannot reproduce this

The only difference here is that on rootful distrobox, the user is added to the sudoers only if it's sudo also on the host But you should be as, well you're using a rootful distrobox :joy:

[termdisc]

Using distrobox create --root ... works as expected based on my experience in v1.5.0.2 and earlier, but it appears to be a big paradigm shift to require --root upon creation and entering of any distrobox container to use sudo to install any packages such as sudo pacman -S or sudo dnf install or sudo apt install.

./distrobox ephemeral -i archlinux:latest -n test (no --root) creates the box and enters it, and I get a first time user password prompt. If I immediately attempt sudo pacman -S git, I get told my user is not in sudoers. In v1.5.0.2 and earlier, I could have continued on with installing packages.

If I run the same except with ./distrobox ephemeral --root ..., running sudo pacman -S git works as expected. However, for system security/stability purposes, I would rather not use --root on every container if all I am aiming to do is install packages to be used within the container.

[89luca89]

Seems like you're using docker (with yourself in the docker group) and not podman? Because to detect if you're in a rootful container, the init checks if root (in the container) can access /etc/shadow on the host, which is a file that exclusively a real root user can access

And this is possible either with a rootful container, or (if you didn't specify --root) with passwordless docker (you in the docker group)

Anyway even with that setup, it's the same as --root, it detects a rootful daemon and prompts you to setup the password But in both cases the group detection is the same, so if you're in sudo/wheel you'll also be in the container

Can you send the podman logs of both containers? the one with --root and the one without?

[termdisc]

I am using podman, not docker.

Because to detect if you're in a rootful container, the init checks if root (in the container) can access /etc/shadow on the host, which is a file that exclusively a real root user can access

This sounds like an issue because rootful=1 is popping up in the log when I am running distrobox without root.

Running ./distrobox ephemeral -i archlinux:latest -n test podman log (no --root).txt

> sudo pacman -S git 
[sudo] password for outphase: 
outphase is not in the sudoers file.

Running ./distrobox ephemeral --root -i archlinux:latest -n roottest sudo podman logs.txt

> sudo pacman -S git
[sudo] password for outphase: 
resolving dependencies...
looking for conflicting packages...

Package (7)           New Version  Net Change  Download Size

core/db               6.2.32-1       7.16 MiB       1.33 MiB
core/db5.3            5.3.28-2       7.31 MiB       1.20 MiB
core/perl             5.38.0-1      75.91 MiB      20.26 MiB
extra/perl-error      0.17029-5      0.04 MiB       0.02 MiB
extra/perl-mailtools  2.21-7         0.10 MiB       0.06 MiB
extra/perl-timedate   2.33-5         0.08 MiB       0.03 MiB
extra/git             2.41.0-2      25.81 MiB       6.09 MiB

Total Download Size:    28.99 MiB
Total Installed Size:  116.42 MiB

:: Proceed with installation? [Y/n] 

[Lin-Junhao]

I am running into this issue again, not during the first time entering the container but after a restart. More description here: #928

[archerallstars]

I encounter this issue today with Distrobox 1.6.0.1 on openSUSE Tumbleweed.

I create my Distrobox with:

distrobox create -i ubuntu:22.04 --init --additional-packages "systemd libpam-systemd" -n test --home ~/Distrobox/home-test

Then, I run sudo apt update inside the box, it returns:

myuser is not in the sudoers file.  This incident will be reported.

It seems this issue hasn't been fixed yet.

[termdisc]

@archerallstars I cannot reproduce the error after running your create command

outphase@test /h/outphase> sudo apt update
Hit:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease                                       
Fetched 119 kB in 7s (17.3 kB/s)                                                                       
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
7 packages can be upgraded. Run 'apt list --upgradable' to see them.

You'll need to provide the distrobox-create and podman logs to see what's happening.

[tatnguyennguyen]

I encounter this issue today with Distrobox 1.6.0.1 on openSUSE Tumbleweed.

I create my Distrobox with:

distrobox create -i ubuntu:22.04 --init --additional-packages "systemd libpam-systemd" -n test --home ~/Distrobox/home-test

Then, I run sudo apt update inside the box, it returns:

myuser is not in the sudoers file.  This incident will be reported.

It seems this issue hasn't been fixed yet.

I have the same issue with Distrobox 1.6.0.1 on openSUSE Leap

[tatnguyennguyen]

@archerallstars I cannot reproduce the error after running your create command

outphase@test /h/outphase> sudo apt update
Hit:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:3 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [119 kB]
Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease                                       
Fetched 119 kB in 7s (17.3 kB/s)                                                                       
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
7 packages can be upgraded. Run 'apt list --upgradable' to see them.

You'll need to provide the distrobox-create and podman logs to see what's happening.

Where can I find these logs? Did you mean the output of docker logs <contain_name> ?

[termdisc]

@tatnguyennguyen

Add the --verbose/-v flag to your distrobox create command.

I don't know the exact syntax to get the docker logs, but for podman, I use podman logs -f CONTAINERNAME

[tatnguyennguyen]

@tatnguyennguyen

Add the --verbose/-v flag to your distrobox create command.

I don't know the exact syntax to get the docker logs, but for podman, I use podman logs -f CONTAINERNAME

Oh, thanks! Yeah, docker uses the same syntax. I've just looked at the "verbose" log and docker log but don't find anything that seems suspicious distrobox-create.log docker-container.log

[termdisc]

@tatnguyennguyen

Is there nothing above "Installing basic packages"? If I were to create a new container and run podman logs -f CONTAINER, I get the following:

(~) >>> podman logs -f distrobox-4FrzPX7Ncg
+ stat /run/host/etc/shadow
+ stat -c %u /run/host/etc/shadow
+ [ 65534 = 0 ]
+ [ -n   ]
distrobox: Executing pre-init hooks...
+ printf distrobox: Executing pre-init hooks...\n
+ eval
+ printf distrobox: Installing basic packages...\n
distrobox: Installing basic packages...
[...]

That stuff around /run/host/etc/shadow and before pre-init hooks will be where we are looking for clues as to what is happening.

[tatnguyennguyen]

@tatnguyennguyen

Is there nothing above "Installing basic packages"? If I were to create a new container and run podman logs -f CONTAINER, I get the following:

(~) >>> podman logs -f distrobox-4FrzPX7Ncg
+ stat /run/host/etc/shadow
+ stat -c %u /run/host/etc/shadow
+ [ 65534 = 0 ]
+ [ -n   ]
distrobox: Executing pre-init hooks...
+ printf distrobox: Executing pre-init hooks...\n
+ eval
+ printf distrobox: Installing basic packages...\n
distrobox: Installing basic packages...
[...]

That stuff around /run/host/etc/shadow and before pre-init hooks will be where we are looking for clues as to what is happening.

Sorry, I redirected the output of docker logs command to a file but forgot to redirect stderr. Here is the complete log docker-container.log

[termdisc]

stat -c %u /run/host/etc/shadow is resolving as 0, which implies that the user is root, which in turn makes Distrobox create a rootful container.

I recall that working on #909, it was pointed out that some distros required slightly different root detection methods than what I originally proposed. I am not sufficiently familiar with OpenSUSE to know if this is the case.

I can try setting up a VM to see if I can figure some of this out because you and the other user are having the same issue on OpenSUSE.

[bdemeyer]

I had the same issue on opensuse, but I fixed this in my case by editing the sudoers config file as opensuse has a weird setup for the sudoers file.

First I added my user into the wheel group I did a "visudo" and uncommented the lines:

Defaults targetpw ALL ALL=(ALL:ALL) ALL

and also uncommented the wheel group access

After a reboot the sudo commands no longer asks for the root password but the user password. Then I tested distrobox again and the issue with sudo was no longer there.

Hope this helps others with this issue.

[KorraHarraway]

I had the same issue on opensuse, but I fixed this in my case by editing the sudoers config file as opensuse has a weird setup for the sudoers file.

First I added my user into the wheel group I did a "visudo" and uncommented the lines:

Defaults targetpw ALL ALL=(ALL:ALL) ALL

and also uncommented the wheel group access

After a reboot the sudo commands no longer asks for the root password but the user password. Then I tested distrobox again and the issue with sudo was no longer there.

Hope this helps others with this issue.

Also reproducible here on latest update of Tumbleweed.

If possible, can you specify what you did? Or if it matches exactly what is recommended in this post: https://www.reddit.com/r/openSUSE/comments/ym52a4/comment/iv31bp4/?utm_source=share&utm_medium=web2x&context=3

Tks

[bdemeyer]

It is almost the same then what is mentioned in the other post, however I also commented out the line

Defaults targetpw

This line makes sudo ask for the root password instead of the user password, as is normal on most linux systems. Not sure, but I think this is what was blocking the distrobox in opensuse from working properly as it might expect a different password (user vs root).

[embermann]

I have same problem on OpenSuse Tumbleweed. Distrobox version 1.7.2.1. @bdemeyer guide didn't help in my case. Any news when this can be fixed?

[depeo]

Same issue in OpenSUSE, but you can solve it like this: Run and notice the container id docker ps

Run: docker exec -it container-id /bin/bash You are now in the container as root.

install vim so you can edit /etc/sudoers # pacman -S vim Add: your_username ALL=(ALL:ALL) ALL, save with :wq! and exit, now it will work.