Creating a Debian or Ubuntu LXC with the pct create command makes /etc in the container not world readable.

T

the dunce

New Member
Jan 25, 2025
2
0
1
Hey all, long time Proxmox user, and I've been having networking issues for a few days in new containers that I've made using scripts that spawn LXCs using the pct create command, and I've found the issue is that any container I create from a Debian or Ubuntu template using pct create sets /etc within the container to not be world readable.

For example:

Code: 
root@Proxmox:~# pct create 107 HDD:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst -features keyctl=1,nesting=1 -hostname testdebian -net0 name=eth0,bridge=vmbr0,ip=dhcp -onboot 1 -cores 4 -memory 4096 -unprivileged 1 -rootfs SSD:16
extracting archive '/mnt/pve/HDD/template/cache/debian-12-standard_12.7-1_amd64.tar.zst'
Total bytes read: 521902080 (498MiB, 232MiB/s)
Detected container architecture: amd64
Creating SSH host key 'ssh_host_rsa_key' - this may take some time ...
done: SHA256:kDi6lOIPptLXwhGdYk8diHBhwVX5uPm8Z5waOvTbbCc root@testdebian
Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ...
done: SHA256:pwkGh+1UGFg9LulNFd7qPhUtdyhmbK4habpn5k7J1RA root@testdebian
Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ...
done: SHA256:BZa5P+w6QPpglbzYCGcaQ2BNRPoZt88Ujybd//Y2hDo root@testdebian
Creating SSH host key 'ssh_host_dsa_key' - this may take some time ...
done: SHA256:7ZxKJxRhYzI4m660j3a4fLibx4dHIUFkLjfko8xJxBA root@testdebian
root@Proxmox:~# pct create 108 HDD:vztmpl/ubuntu-24.04-standard_24.04-2_amd64.tar.zst -features keyctl=1,nesting=1 -hostname testubuntu -net0 name=eth0,bridge=vmbr0,ip=dhcp -onboot 1 -cores 4 -memory 4096 -unprivileged 1 -rootfs SSD:16
extracting archive '/mnt/pve/HDD/template/cache/ubuntu-24.04-standard_24.04-2_amd64.tar.zst'
Total bytes read: 564490240 (539MiB, 240MiB/s)
Detected container architecture: amd64
Creating SSH host key 'ssh_host_dsa_key' - this may take some time ...
done: SHA256:d+mS5upe8eNPw78jn67vrekkz8aQdjO3G+D3dg2+KNk root@testubuntu
Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ...
done: SHA256:iqaeBHq5rOTiwh4foex9+TfMyCqiuvJfvU4q2683FJ0 root@testubuntu
Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ...
done: SHA256:5B/7ws5UaxEg4CaZUqcuz/zqB4I59bIMTrxhTjDIadw root@testubuntu
Creating SSH host key 'ssh_host_rsa_key' - this may take some time ...
done: SHA256:8Scnhq6ghdV0JFC+usGoxdqm0RscXCQ6OEz3VkAFLMM root@testubuntu
root@Proxmox:~# pct mount 107
mounted CT 107 in '/var/lib/lxc/107/rootfs'
root@Proxmox:~# pct mount 108
mounted CT 108 in '/var/lib/lxc/108/rootfs'
root@Proxmox:~# cd /var/lib/lxc/
root@Proxmox:/var/lib/lxc# ls -ald ./107/rootfs/etc
drwxrwx--- 62 100000 100000 136 Jan 25 11:28 ./107/rootfs/etc
root@Proxmox:/var/lib/lxc# ls -ald ./108/rootfs/etc
drwxrwx--- 78 100000 100000 163 Jan 25 11:28 ./108/rootfs/etc

This does not happen with Alpine containers, or containers that I create using the PVE GUI (even if I set the same options I have in the pct create command in the block above). I've tried changing the options on the pct create command, and none of them seem to change this behavior at all. I've decompressed and opened the container templates and confirmed /etc is world readable within them, and tried deleting and re-downloading them, so it seems like something in the pct create process is changing these permissions.

I'm on pve-manager/8.3.3/f157a38b211595d6 (running kernel: 6.8.12-7-pve) and all packages are up to date. If anyone has any ideas for what could be causing this or suggestions I would greatly appreciate them.
 
Hi,
thank you for the report! I can reproduce this issue here. It seems like the umask (from the environment in which the pct enter command is issued) gets inherited during the creation of the container.
 
This was indeed my umask setting on the host causing this. I changed it ages ago but had only created Alpine containers since then, so it hadn't affected me yet. Thanks for the help!
 
Still, seems like it might be a bug in tar that can happen in our specific case with the --skip-old-files flag and when the archive contains a file in a subdirectory before the subdirectory itself:
Code: 
[I] root@pve8a1 ~/testdir# tar tvf ../a.tar 
-rw-r--r-- root/root         4 2025-01-27 14:51 etc/bar
drwxr-xr-x root/root         0 2025-01-27 14:51 etc/
hrw-r--r-- root/root         0 2025-01-27 14:51 etc/bar link to etc/bar
[I] root@pve8a1 ~/testdir# umask 0777
[I] root@pve8a1 ~/testdir# tar xpf ../a.tar --skip-old-files
[I] root@pve8a1 ~/testdir# ls -l
total 4
d--------- 2 root root 4096 Jan 27 15:04 etc/
[I] root@pve8a1 ~/testdir# rm * -r
[I] root@pve8a1 ~/testdir# tar xpf ../a.tar
[I] root@pve8a1 ~/testdir# ls -l
total 4
drwxr-xr-x 2 root root 4096 Jan 27 14:51 etc/
I think what happens is that the directory is auto-created when etc/bar is extracted and thus the umask is in effect, but then the actual entry for etc is skipped because of --skip-old-files even though it didn't exist before extracting.
 
You must log in or register to reply here.
Top Bottom