Issues with accessing files in mounted disk

LXD
1

I created a disk device pointing a directory on the host to automatically managed SSL certificates. Intention is to offer additional services secured via those same certificates.

The certificates are mounted inside the container under /mnt/ssl. It looks like so:

# ls -l /mnt/ssl
total 20
-rw-r--r-- 1 nobody nogroup 2212 Feb  7 18:22 cert1.pem
-rw-r--r-- 1 nobody nogroup 3750 Feb  7 18:22 chain1.pem
-rw-r--r-- 1 nobody nogroup 5962 Feb  7 18:22 fullchain1.pem
-rw-r----- 1 nobody nogroup 3268 Feb  7 18:22 privkey1.pem

I have my service inside the container run as a service user (“kibana”). That user obviously can’t read any of these files. Not knowing how else to proceed, I added kibana to ‘nogroup’:

# adduser kibana nogroup

Whether that’s the recommended solution or not, permission-wise, this should work, should it not? However, it doesn’t:

kibana:/mnt/ssl$ cat privkey1.pem 
cat: privkey1.pem: Permission denied

I realize that this is likely a crude solution to the problem, and if one solves for this differently, please point me in the right direction. However, why doesn’t this work?

Thanks,
Stephan

2

Please show lxc config show <instance> --expanded and ls -lt <dir> of the source dir on the host.

3

This touches a couple of areas I’ve been exploring lately. One is indeed how to centrally manage all the individual certs for the various containers on each host (and other devices). I’m very sad to see Certera seems to be dead, for example. I haven’t yet found a solution I like, so this is a WIP for me.

The most helpful document on attaching disks and managing permissions in LXD/LXC I could find (and it is not very easy to find in Google, for some reason) is here.

4

Thomas, here we go:

$ lxc config show kibana
architecture: x86_64
config:
  image.architecture: amd64
  image.description: ubuntu 22.04 LTS amd64 (release) (20230107)
  image.label: release
  image.os: ubuntu
  image.release: jammy
  image.serial: "20230107"
  image.type: squashfs
  image.version: "22.04"
  volatile.base_image: ed7509d7e83f29104ff6caa207140619a8b235f66b5997f1ed6c5e462617fb71
  volatile.cloud-init.instance-id: bc4af271-f8e5-4862-8ed9-b49cb7f97eaf
  volatile.eth0.host_name: veth3098cf04
  volatile.eth0.hwaddr: 00:16:3e:43:d5:dd
  volatile.idmap.base: "0"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1000000,"Nsid":0,"Maprange":1000000000},{"Isuid":false,"Isgid":true,"Hostid":1000000,"Nsid":0,"Maprange":1000000000}]'
  volatile.last_state.idmap: '[]'
  volatile.last_state.power: RUNNING
  volatile.uuid: 62f954b0-5646-4cd7-806c-d0d126490258
devices:
  proxy5601:
    connect: tcp:127.0.0.1:5601
    listen: tcp:127.0.0.1:5601
    type: proxy
  ssl-certs:
    path: /mnt/ssl
    source: /var/certs/certbot/
    type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""

$ sudo ls -lt /var/certs/certbot/
total 20
-rw-r--r-- 1 root root 2212 Feb  7 18:22 cert1.pem
-rw-r--r-- 1 root root 3750 Feb  7 18:22 chain1.pem
-rw-r--r-- 1 root root 5962 Feb  7 18:22 fullchain1.pem
-rw-r----- 1 root root 3268 Feb  7 18:22 privkey1.pem

Thanks for any pointers.

5

OK, so the files are owned by root on the host (real root), but root in the container is a different UID/GID because you are using unprivileged container (this is good).

All the files except from privkey1.pem are globally readable so they should already be readable in the container, but you’re going to need the private key for the daemon so we need to fix that.

What you can do is set the shift: true property on the ssl-certs disk device.

Sets up a shifting overlay to translate the source UID/GID to match the instance (only for containers)

See https://linuxcontainers.org/lxd/docs/master/reference/devices_disk/#device-options

Then you should see the files owned by root in the container.

6

Thomas, thank you for the reply. Indeed, the files are now owned by root in the container.

(as an aside, my brain doesn’t intuit the order of parameters when changing a configuration parameter; I keep wanting to enter lxc config kibana set device ssl-certs shift=true, but of course that’s wrong and you need to enter lxc config device set kibana ssl-certs shift=true, which seems…odd to me).

In any case, I now have a different problem that’s not LXC related (the daemon in the container is running as user ‘kibana’, and files are owned by ‘root’ now).

Any way I can make those files not be owned by root but by ‘kibana’ inside the container? That’s probably a bad idea, but I thought I’d ask anyway.

Thanks,
Stephan

7

You have privkey1.pem group readable so maybe you could change the group of the file in the host? If so, you should note what’s the GID in the instance (GID=$(lxc exec kibana -- getent group kibana | cut -d: -f 3)) and chrgp $GID privkey1.pem in the host.