`lxd init` invoked as normal user fails to find lvm thin-provisioning tools

[gibmat]

Required information

• Distribution: Debian
• Distribution version: sid
• The output of "lxc info" or if that fails:
  • Kernel version: 6.1.8-1
  • LXC version: 5.0.2
  • LXD version: 5.0.2
  • Storage backend in use: lvm -- 2.03.16(2) (2022-05-18) / 1.02.185 (2022-05-18) / 4.47.0

Issue description

Originally reported as Debian bug #1027321; I've waited a while to see if the original reporter would confirm my workaround as described below, but that hasn't happened yet and I wanted to get the bug forwarded.

The original reporter ran into an issue performing a lxd init as a normal user who had already been added to the "lxd" group. They were trying to configure a lvm storage backend, but LXD wasn't able to find the thin-provisioning tools even though they were properly installed. It appears this is caused by the thin_check binary existing under /usr/sbin/, which isn't in a normal user's path by default.

I have reproduced the issue, and verified that lxd init works correctly if I explicitly add /usr/sbin/ to my path when running that command. The logic for this check (https://github.com/lxc/lxd/blob/master/lxd/main_init_interactive.go#L903) relies on os/exec, and I'm not sure if there's an easy way to inject /usr/sbin/ when LookPath() is called.

Steps to reproduce

Without modifying $PATH

gibmat@tharkun:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
gibmat@tharkun:~$ id
uid=1000(gibmat) gid=1000(gibmat) groups=1000(gibmat),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),112(bluetooth),114(lpadmin),117(scanner),124(lxd)
gibmat@tharkun:~$ lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (dir, lvm, zfs) [default=zfs]: lvm
Create a new LVM pool? (yes/no) [default=yes]: 
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]: 
Size in GiB of the new loop device (1GiB minimum) [default=30GiB]: 

The LVM thin provisioning tools couldn't be found. LVM can still be used
without thin provisioning but this will disable over-provisioning,
increase the space requirements and creation time of images, containers
and snapshots.

If you wish to use thin provisioning, abort now, install the tools from
your Linux distribution and run "lxd init" again afterwards.

Do you want to continue without thin provisioning? (yes/no) [default=yes]: ^C

Modified $PATH

gibmat@tharkun:~$ PATH=$PATH:/usr/sbin lxd init
Would you like to use LXD clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (dir, lvm, zfs) [default=zfs]: lvm
Create a new LVM pool? (yes/no) [default=yes]: 
Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]: 
Size in GiB of the new loop device (1GiB minimum) [default=30GiB]: 
Would you like to connect to a MAAS server? (yes/no) [default=no]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: no
Would you like to configure LXD to use an existing bridge or host interface? (yes/no) [default=no]: yes
Name of the existing bridge or host interface: lxcbr0
Would you like the LXD server to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: 
Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]: 

[stgraber]

Ignoring the current PATH doesn't really feel right in general and may also affect our ability to test or limit some of those commands by altering PATH to use alternative versions of the binaries being looked for.

[stgraber]

A reasonable fix would be to tweak the error a tiny bit to hint that it wasn't found in the normal lookup PATH so the user may get the hint that they need to include it in their PATH or run as root.

[tomponline]

Ive not looked into this in great detail yet, but I was thinking we could check the lvm thin tools as part of checking which storage pool drivers were available on the server and send a hint back to the lxd init client.

[stgraber]

Yeah, that'd be an alternative, having an extra field in the DriverInfo which is then plumbed all the way to be stored in memory and returned in /1.0 output. It's definitely possible though it's honestly more work than I'm willing to put into this at this point ;)

Especially for a driver that's as unpopular as LVM :)