New user in LXC instance (in LXD) cannot use sudo, even though an admin

Ubuntu Version: Ubuntu Core 26.04

Desktop Environment (if applicable): n/a (server, not a desktop)

Background:

  • I’ve installed Ubuntu Core 26.04 (currently as a VM in VirtualBox to experiment, with the intention to install it on my server).
  • I have created a new VM in LXD and LXC as per instructions (which, bizarrely, I can’t find now).
  • I can get into the LXC VM just fine.

The situation is that the VM has only one user, specifically root. I would like to have a separate admin user, because it helps me control access via Tailscale.

I can create the admin user easily (within the LXC instance).

lxc:$~ sudo useradd --create-home --groups=sudo --shell=/bin/bash alice

Problem Description:

The problem is that when logging in as Alice in the LXC, the user cannot use sudo.

localhost:~$ sudo lxc exec ziggy -- su - alice

lxc:~$ id
uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo)

lxc:~$ sudo true
sudo: sudo must be owned by uid 0 and have the setuid bit set

I have tried every which way that I can find to allow Alice to use sudo, but I simply cannot fix this.

Relevant System Information:

lxc~$ id root
uid=0(root) gid=0(root) groups=0(root)

lxc:~$ type sudo
sudo is hashed (/usr/bin/sudo)

lxc:~$ ls -l /usr/bin/sudo
lrwxrwxrwx 1 root root 22 Mar 13 11:02 /usr/bin/sudo -> /etc/alternatives/sudo

lxc:~$ ls -l /etc/alternatives/sudo
lrwxrwxrwx 1 root root 23 Jun 27 16:25 /etc/alternatives/sudo -> /usr/lib/cargo/bin/sudo

lxc~$ ls -l /usr/lib/cargo/bin/sudo
-rwsr-xr-x 1 root root 1082656 Mar 11 13:27 /usr/lib/cargo/bin/sudo

Question:

How do I allow Alice to use sudo?

What I’ve Tried:

I’ve followed a bunch of instructions from AI, ranging from hard-linking /usr/lib/cargo/bin/sudo to /bin/sudo, to messing with update-alternatives.

According to the AI, which of course does make mistakes, “It appears to be a namespace privilege/mapping issue unique to sudo-rs handling user transitions inside an unprivileged LXD VM container environment.”

Are you sure you are running a VM (that requires special setup IIRC) and not just a system container ?

How do you enter the instance?

(Should be something like: lxc shell <instance name> Which will spawn a root shell inside the instance)

I once wrote a blog post about how to use lxc on an UbuntuCore system (to build, test and run snap packages without touching the host system), you can find it here:

2 Likes

I don’t know! I don’t understand this much. I’ve been trying to learn how to use Ubuntu Core. I think that it was you who suggested LXD.

Here is how I did it.

snap install lxd
lxd init --auto
sudo lxc launch ubuntu:26.04 ziggy
sudo lxc shell ziggy

From there, I created the new user as described in my previous post.

EDIT: This is on a fresh installation of Ubuntu Core.

1 Like

Right, that’s the proper way and gives you a system container (pretty much like a VM but without all the nasty overhead (and it is sharing the host kernel, so you do not need to bother with bootloader stuff etc))

I must admit that I actually never bother to set up any user though, but it should not be any different from doing it on a normal physical install… (is there a particular reason you want the user instead of just using root ?)

I just tried it though…:

ogra@styx:~$ lxc launch ubuntu:26.04 stonking
Launching stonking
ogra@styx:~$ lxc shell stonking
root@stonking:~# adduser ogra
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for ogra
Enter the new value, or press ENTER for the default
    Full Name :
    Room Number :
    Work Phone :
    Home Phone :
    Other :
Is the information correct? [Y/n]
root@stonking:~# adduser ogra sudo
root@stonking:~# su ogra
ogra@stonking:/root$ sudo ls /
[sudo: authenticate] Password:
bin  boot  dev	etc  home  lib	media  mnt  opt	 proc  root  run  sbin	snap  srv  sys	tmp  usr  var
ogra@stonking:/root$

perhaps lxc exec limits your environment somehow …

Edit: You can also use lxc shell to enter the container as user like:

ogra@styx:~$ lxc shell stonking -- sh -c 'su ogra'
ogra@stonking:/root$ sudo ls /
[sudo: authenticate] Password:         
bin  boot  dev	etc  home  lib	media  mnt  opt	 proc  root  run  sbin	snap  srv  sys	tmp  usr  var
ogra@stonking:/root$ 
2 Likes

Yes. I use Tailscale, and I need the container to have a user that isn’t root for security reasons.

Oh, wow! OK, I can’t test this now, but I’m going to try again using your method instead of my method. If it works with your method, I’ll try to figure out the difference between your and my methods.

I’ll report back what happens.

You could just install it natively without having all the hassle to wrap it in a container:

https://snapcraft.io/tailscale

2 Likes

Oh! I see that it’s a bit out of date, but it’s worth trying.

I also use Syncthing, and I see that there’s an up-to-date version in snap as well.

Thanks for the info. More for me to try!

Meanwhile…

I’ve tried using your method to create the new user, exactly as you typed, but I still get that error message:

sudo: sudo must be owned by uid 0 and have the setuid bit set

I can’t understand why you and I have a different result.

EDIT: I can’t use the snap version of Tailscale, because:

tailscale ssh will not work.

I’ve just noticed something. How are you using lxc without sudo? I have to use sudo when using lxd and lxc.

See the last few lines on my blog post (the stuff in brackets)… though note that I’m running all this on my laptop… but it shouldn’t make any difference inside the container where you run it

1 Like

That worked, thank you!

Now, the big sticking point is the sudo error message. Have you any clue why I have the problem and you don’t?

Inside the container, please would you list the sudo command as I did in the original post (type sudo, etc)? I’d like to see if you have the same setup as I do.

Unless you have a different version of Ubuntu Core from me. I’m using 26.04, which is also what I used when creating my LXC container. Which one are you using?

Indeed I do, we are both using a 26.04 container, if anything would differ that would be quite a bug :slight_smile:

ogra@styx:~$ lxc shell stonking -- sh -c 'su ogra'
ogra@stonking:/root$ cd
ogra@stonking:~$ id
uid=1001(ogra) gid=1001(ogra) groups=1001(ogra),27(sudo),100(users)
ogra@stonking:~$ sudo true
[sudo: authenticate] Password:         
ogra@stonking:~$ id root
uid=0(root) gid=0(root) groups=0(root)
ogra@stonking:~$ type sudo
sudo is hashed (/usr/bin/sudo)
ogra@stonking:~$ ls -l /usr/bin/sudo
lrwxrwxrwx 1 root root 22 Mar 13 11:02 /usr/bin/sudo -> /etc/alternatives/sudo
ogra@stonking:~$ ls -l /etc/alternatives/sudo
lrwxrwxrwx 1 root root 23 Jun 27 16:27 /etc/alternatives/sudo -> /usr/lib/cargo/bin/sudo
ogra@stonking:~$ ls -l /usr/lib/cargo/bin/sudo
-rwsr-xr-x 1 root root 1053944 Mar 11 13:27 /usr/lib/cargo/bin/sudo
ogra@stonking:~$ 

My laptop runs 26.04, the container is 26.04 (as you can see from my lxc launch command above)

2 Likes

Thank you.

My user didn’t belong to the group users, so I’ve added it.

But that made no difference. I get the same results as you do, with the one exception that I can’t use sudo.

Aargh!

Tomorrow, I’ll destroy the machine (metaphorically) and reinstall Ubuntu Core 26.04 from scratch. Maybe something strange happened during the installation.

I’ll report back here.

2 Likes

Well, Oliver, I have completely reinstalled Ubuntu Core from scratch.

And I still have the problem with sudo.

I’m at my wit’s end here. I have no clue how to diagnose or solve this problem. I cannot understand why you can use sudo, and I cannot. Everything that I’ve done mirrors yours, yet the outcome differs.

This is unbelievably frustrating.

Do you have any suggestions whatsoever as to how I could proceed, please?

Well, I just tried again on a spare UbuntuCore18 (I sadly don’t have a device with Core26 around ATM) just to make sure it isn’t a desktop vs UC issue …

ogra@pi4:~$ cat /etc/os-release 
NAME="Ubuntu Core"
VERSION="18"
ID=ubuntu-core
PRETTY_NAME="Ubuntu Core 18"
VERSION_ID="18"
HOME_URL="https://snapcraft.io/"
BUG_REPORT_URL="http://bugs.launchpad.net/snappy/"
ogra@pi4:~$ sudo lxc launch ubuntu:26.04 stonking
Launching stonking
ogra@pi4:~$ sudo lxc shell stonking                  
root@stonking:~# adduser ogra
New password: 
Retype new password: 
passwd: password updated successfully
Changing the user information for ogra
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] 
root@stonking:~# adduser ogra sudo
root@stonking:~# su - ogra
ogra@stonking:~$ sudo ls /
[sudo: authenticate] Password:         
bin  boot  dev	etc  home  lib	media  mnt  opt	 proc  root  run  sbin	snap  srv  sys	tmp  usr  var
ogra@stonking:~$ 
logout
root@stonking:~# 
logout
ogra@pi4:~$

I wonder if the fact that you run inside a VM might have any impact here, perhaps the stacking of kernels or kernel features gets in your way, not really sure …

That would be truly weird. The system doesn’t know that it’s running in a VM, and in any case it shouldn’t affect how one user sees sudo. Inside the LXC instance, the root user can use sudo. Why does it suddenly complain with a different user?

The bit that really confuses me is the message.

sudo: sudo must be owned by uid 0 and have the setuid bit set

But, everything points to the message being incorrect.

I’m going to try posting this on Reddit later, in case someone there has a clue. If I make any progress, I’ll report back here.

Some things I noticed re-reading your pastes…

Your prompt after entering the container did not show the container name but “lxc”, this is weird since IIRC normally .bashrc or the .profile file have code setting this specific prompt (can’t remember which of the two)…

Did you use adduser in your later tests (you used useradd in your first post, useradd is pretty low level and lacks a bunch of defaults which is why in debian based systems the adduser wrapper exists (you should always prefer adduser over useradd unless you explicitly want to omit some defaults))

Both might have some impact beyond any possible kernel stacking issues…

1 Like

My bad; I had edited this for brevity and clarity. I should have said so, sorry.

Yes, I did. In fact, I copied your commands and pasted them into my terminal, even using your name ogra!

I didn’t know that. I’ve documented this, thank you.

That will only work with the respective password that only I know :rofl:

3 Likes

You’ve speculated about this being an issue with sudo-rs. It sure looks like it, because that message is from sudo. But then, why would it ever work? Perhaps it doesn’t or can’t follow the symbolic link (chain) and simply reads the mode bits from say /usr/bin/sudo? Or could AppArmor have a hand in this? Is it possible to mask the SUID bit?