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

[paddylandau]

@peterwhite23

But then, why would it ever work?

Yes, exactly! That confuses me so much.

@peterwhite23

Perhaps it doesn’t or can’t follow the symbolic link (chain) and simply reads the mode bits from say /usr/bin/sudo?

I’ve checked, and the user definitely can read the chain. That’s not a problem. The user can even see the contents of /usr/lib/cargo/bin/sudo (using view). I’ve gone so far as to delete the link /usr/bin/sudo and hard-link /usr/lib/cargo/bin/sudo to it or to copy the file (remembering setuid).

@peterwhite23

Is it possible to mask the SUID bit?

Do you mean chmod -s /usr/lib/cargo/bin/sudo? I’ve just tried that, but it didn’t help.

@peterwhite23

could AppArmor have a hand in this?

Good question. When I last tried to understand how to use AppArmor, I completely failed; it was above my comprehension level. So, I have no idea how to check!

---

Returning to the error message:

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

We can look at the links and sudo itself:

alice@abercorn:~$ ls -l /usr/bin/sudo /etc/alternatives/sudo /usr/lib/cargo/bin/sudo
lrwxrwxrwx 1 root root      23 Jun 27 16:25 /etc/alternatives/sudo -> /usr/lib/cargo/bin/sudo
lrwxrwxrwx 1 root root      22 Mar 13 11:02 /usr/bin/sudo -> /etc/alternatives/sudo
-rwsr-xr-x 1 root root 1082656 Mar 11 13:27 /usr/lib/cargo/bin/sudo

We see that the setuid bit is set.

We see that it’s owned by root, which has uid 0:

alice@abercorn:~$ id root
uid=0(root) gid=0(root) groups=0(root)

Plus, Alice belongs to the sudo group:

alice@abercorn:~$ id
uid=1002(alice) gid=1002(alice) groups=1002(alice),27(sudo),100(users)

So, what exactly is the error message telling us? It’s obviously telling us something other than what it appears to be telling us.

[peterwhite23]

@paddylandau

@peterwhite23

Perhaps it doesn’t or can’t follow the symbolic link (chain) and simply reads the mode bits from say /usr/bin/sudo?

I’ve checked, and the user definitely can read the chain. That’s not a problem. The user can even see the contents of /usr/lib/cargo/bin/sudo (using view). I’ve gone so far as to delete the link /usr/bin/sudo and hard-link /usr/lib/cargo/bin/sudo to it or to copy the file (remembering setuid).

It’s not about what the user can do, it’s what sudo-rs does (not) or can (not) do.

@paddylandau

@peterwhite23

Is it possible to mask the SUID bit?

Do you mean chmod -s /usr/lib/cargo/bin/sudo? I’ve just tried that, but it didn’t help.

No, the question was in the context of AppArmor (AA). Can it be responsible for sudo not seeing the SUID bit for some reason? I have since found the capability setuid rule, so that being missing in the effective AA profile could be an explanation, I guess.

[paddylandau]

Thanks. As I say, I don’t understand AppArmor, so I wouldn’t know where to even start looking.

[peterwhite23]

The question was more for the broader audience, so you don’t have to answer it. I just wanted to throw it out there. Perhaps someone with a better understanding can make sense of this.

BTW, what are the space requirements for that LXD setup, including the 26.04 container? As always, I’m strapped for storage space, but I’d like to see if I can reproduce the issue.

[ogra]

While AA is a kernel feature, the rules are defined in userspace, so if we use the same image (which we did in all the tests above) these rules must be identical. The one difference here is real HW vs emulated VM hardware.

LXD makes heavy use of the hypervisor and my assumption still stands that this has something to do with the VM implementation itself (or the config) so that not all kernel features are routed through to the container …

[peterwhite23]

@ogra

While AA is a kernel feature, the rules are defined in userspace, so if we use the same image (which we did in all the tests above) these rules must be identical.

But you didn’t use the same image. Yours is core-18 and @paddylandau’s is core-26 from here, I suppose.

[ogra]

I was referring to the lxd container image (26.04) where the apparmor config lives…

I have just tested in qemu on top of an UC26 install and it works the same as on 26.04 desktop or UC18, I have never used VirtualBox for any core images so I can not actually judge what might be wrong there but I can definitely not reproduce it in any of my setups…

EDIT: Perhaps something like this is necessary:

https://www.virtualbox.org/manual/ch09.html#nested-virt

[paddylandau]

@peterwhite23

@paddylandau’s is core-26 from here

That’s correct.

@ogra

Perhaps something like this is necessary:

https://www.virtualbox.org/manual/ch09.html#nested-virt

Yes, it is necessary, and it is enabled. Without it, nested virtualisation shouldn’t be possible. It’s the virtual machine’s equivalent of a computer’s BIOS setting to allow virtualisation.

The question, again, comes back to why root in the LXC instance can access sudo, but the new user in the same LXC instance cannot, due to an incorrect message. This should be entirely independent of the host, because it’s not using the host’s files.

I wish that I had a spare bare metal computer to test this on. That would definitively tell us whether or not it has anything to do with nested virtualisation.

[ogra]

@paddylandau

I wish that I had a spare bare metal computer to test this on.

You could just try in qemu
As i said before, it is just a matter of copy/paste from

https://documentation.ubuntu.com/core/how-to-guides/manage-ubuntu-core/test-on-qemu/

[peterwhite23]

@paddylandau

Here is how I did it.

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

Well, I’ve just tried the above and this is what happened:

snap install lxd
lxd init --auto
sudo lxc launch ubuntu:26.04 ziggy
sudo lxc shell ziggy
lxd (5.21/stable) 5.21.5-f2a1a0e from Canonical✓ installed
Error: Failed to connect to local LXD: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
If this is your first time running LXD on this machine, you should also run: lxd init

Launching ziggy
Error: Failed instance creation: Failed creating instance record: Failed initialising instance: Failed getting root disk: No root device could be found
Error: Failed to fetch instance "ziggy" in project "default": Instance not found

I copy/pasted the whole code block, so that’s why the message don’t show immediately after the respective commands.

I reinstalled the UC image on the same Ubuntu Core VM, because I had wiped the TPM and ended up like this fellow user. So I selected “Install using 20260506” from the grub menu, let it do its thing and then did the above.

After a reboot:

peterwhite23@localhost:~$ lxd init --auto
Error: Failed to connect to local LXD: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
peterwhite23@localhost:~$ snap purge lxd
error: unknown command "purge", see 'snap help'.
peterwhite23@localhost:~$ snap remove --purge lxd
lxd removed
peterwhite23@localhost:~$ snap install lxd
lxd (5.21/stable) 5.21.5-f2a1a0e from Canonical✓ installed
peterwhite23@localhost:~$ lxd init --auto
Error: Failed to connect to local LXD: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
peterwhite23@localhost:~$ ping ubuntu.com
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?

I then figured that I might need to do a factory reset, so I did. But now I cannot even login anymore; guess the SSH key import was not included in the reset, because I now get a login prompt instead of the SSH details MOTD.
I think, I need a break from this.

[ogra]

@peterwhite23

lxd init --auto

This always requires sudo (being the initial setup If the daemon itself)… (also. If you want to see what it actually does you can run it interactively by omitting –auto)

The later lxc commands don’t if you are on a classic system (on core you will need to tinker with the groups file if you want to use it without sudo)

[paddylandau]

@ogra

You could just try in qemu

Thank you. As per instructions, I’m downloading test-snapd-swtpm now. The connection is unbelievably slow. At this rate, it’s going to be an hour to complete downloading even though I’m on a fast broadband.

In the meantime, I tested using the alternative (and recommended) multipass. That was quick and dead easy — but I got the same error with sudo

I’ll report back when I can get the qemu version running.

[peterwhite23]

@paddylandau

The question, again, comes back to why root in the LXC instance can access sudo, but the new user in the same LXC instance cannot, due to an incorrect message.

I can answer the first part. Because root is the owner and already uid 0, there is no need to call setuid().

[paddylandau]

It finally downloaded.

I followed the instructions to start a virtual machine with TPM and full-disk encryption. It started up correctly, and I was able to install and initialise LXD.

But, lxc launch … failed with the error that there was insufficient space on disk.

I have looked through the command sudo qemu-system-x86_64 …, and I cannot find where it specifies a virtual disk to use. It obviously uses ubuntu-core-26-amd64.img as the Live USB, but where does it store the virtual disk? How do I ensure that the disk size is sufficient?

[paddylandau]

@peterwhite23

I can answer the first part. Because root is the owner and already uid 0, there is no need to call setuid().

Alas, that doesn’t mean anything to me! I love using Linux, but there’s so much of it that I have no understanding of.

[peterwhite23]

@paddylandau

But, lxc launch … failed with the error that there was insufficient space on disk.

That is most likely caused by the core image being too small. I ran into the same problem. I guess I can just truncate -s+5G ubuntu-core-26-amd64.img or whatever to make more unallocated space available in the VM. Virtualbox (VB), not being able to run raw images may need something else.

BTW, why don’t you give Virtual Machine Manager (VMM aka virt-manager) a spin? I have switched from VB a while ago and never looked back. Things to look out for:

• by default (at least in 24.04) VM’s are installed with BIOS firmware and one cannot (easily) change that once the machine has been created. One can change that in the preferences menu, though, so new machines get UEFI.
• Secure Boot and TPM may not be enabled, but one can edit the XML config in VMM:

  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-noble">hvm</type>
    <firmware>
      <feature enabled="yes" name="enrolled-keys"/>
      <feature enabled="yes" name="secure-boot"/>
    </firmware>
  </os>
  

  or just copy and adapt the config I posted in the other thread — need to allow XML editing in VMM prefs.

[peterwhite23]

It’s all about the user id (uid). The root account will always have the special value 0. Some programs, like sudo need to elevate their privileges by means of the setuid() system call (see man 2 setuid). To be able to do so, the program binary needs to have the SUID bit set (chmod o+s foo) and be owned by the uid in question.

[paddylandau]

@peterwhite23

I can just truncate -s+5G ubuntu-core-26-amd64.img or whatever to make more unallocated space available in the VM.

I’ll try that! Probably tomorrow, because I’m running out of time today.

@peterwhite23

Virtualbox (VB), not being able to run raw images may need something else.

It does indeed use a different approach.

@peterwhite23

why don’t you give Virtual Machine Manager (VMM aka virt-manager) a spin?

Whew! We now have VirtualBox, QEMU, Multipass, and VMM! I like VirtualBox, because it’s so easy to change the settings and see what’s going on. I’m only trying Multipass and QEMU to see if they give different results. So far, Multipass is the same. I’ll try your trick with truncate in QEMU.

@peterwhite23

To be able to do so, the program binary needs to have the SUID bit set (chmod o+s foo) and be owned by the uid in question.

Which is the case! That’s why it’s confusing. The error message doesn’t match what’s happening in the machine.

[ogra]

There is a qemu frontend offered by Canonical that might make things easier (I never use it so I tend to forget it exists )

https://documentation.ubuntu.com/core/tutorials/try-pre-built-images/install-on-a-vm/

These images should be properly resized already

EDIT: oops, you mentioned it above already, I missed that, it is definitely the most comfortable way of using qemu…

[peterwhite23]

@paddylandau

Whew! We now have VirtualBox, QEMU, Multipass, and VMM!

VMM isn’t like VB. It’s just a frontend to the libvirt abstraction library, so it can run any virtual machine that libvirt understands, e.g. QEMU/KVM, lxc, you name it, it’s probably got it.

Consider VMM as VirtualBox on steroids.