[PATCH container] fix #8295: mount all: do not let umask restrict the rootfs directories

[PATCH container] fix #8295: mount all: do not let umask restrict the rootfs directories

[Lucas Barros]

mount_all() creates /var/lib/lxc/<vmid>/rootfs with make_path(), which
honors the umask of the calling process. When 'pct restore' or
'pct create' is run from a root shell with a restrictive umask like
0077, both /var/lib/lxc/<vmid> and its rootfs directory end up with
mode 0700. For unprivileged containers, the archive is then extracted
by the mapped root user via lxc-usernsexec, which cannot traverse
/var/lib/lxc/<vmid> anymore, so the extraction fails with "Permission
denied", the restore or creation is aborted and the new volume is
removed again.

Create the directories with mode 0755 independent of the umask, which
is what they get with the default umask anyway.

Signed-off-by: Lucas Barros <lucasbarros.kam@gmail.com>
---
Reproduced on a PVE 9 node (pve-container 6.1.18) with a local vzdump
archive of an unprivileged Debian 13 container; the reporter used a
PBS archive, which goes through the same mount_all() call in the
create/restore API before extracting:

before:
  $ (umask 0077; pct restore 9911 vzdump-lxc-9910-....tar.zst \
      --storage local --unprivileged 1); echo "exit=$?"
  tar: /var/lib/lxc/9911/rootfs: Cannot open: Permission denied
  ...
  exit=255
  $ stat -c '%A %U %n' /var/lib/lxc/9911 /var/lib/lxc/9911/rootfs
  drwx------ root /var/lib/lxc/9911
  drwx------ root /var/lib/lxc/9911/rootfs
  $ (umask 0077; pct create 9912 local:vztmpl/debian-13-... \
      --rootfs local:1 --unprivileged 1); echo "exit=$?"
  tar: /var/lib/lxc/9912/rootfs: Cannot open: Permission denied
  exit=255

after:
  restore with umask 0077: exit=0
  drwxr-xr-x root /var/lib/lxc/9911
  drwxr-xr-x root /var/lib/lxc/9911/rootfs
  create from template with umask 0077: exit=0

A privileged restore with umask 0077 worked before and still does.
With the default umask nothing changes, as the directories already get
mode 0755 there.

The 'chmod' option of make_path() only applies to directories it
creates, so the mode of an already existing /var/lib/lxc/<vmid> is not
touched. I did not test with a PBS archive, as the lab node has no PBS.

The pve-container test suite passes before and after.
proxmox-perltidy reports no changes.

This patch was prepared with the help of an LLM based coding assistant;
I reviewed the change and ran the tests mentioned above myself.

 src/PVE/LXC.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
index 59d803d..41258b6 100644
--- a/src/PVE/LXC.pm
+++ b/src/PVE/LXC.pm
@@ -1780,7 +1780,9 @@ sub mount_all {
     my ($vmid, $storage_cfg, $conf, $ignore_ro) = @_;
 
     my $rootdir = "/var/lib/lxc/$vmid/rootfs";
-    File::Path::make_path($rootdir);
+    # The mapped root user of an unprivileged container needs to traverse these directories, for
+    # example when extracting an archive, so do not let a restrictive umask get in the way.
+    File::Path::make_path($rootdir, { chmod => 0755 });
 
     my $volid_list = PVE::LXC::Config->get_vm_volumes($conf);
     PVE::Storage::activate_volumes($storage_cfg, $volid_list);
-- 
2.47.3