You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create containers with a fixed umask, not the operator's
Answers the question in the thread directly: why does the GUI produce a
working container from the same template when the script does not?
Because pct create extracts the template under the umask of whoever called it.
The GUI calls it from pvedaemon, which systemd starts with 022. We are called
from the operator's shell, so a hardened 027 there gives /etc 750 -- and apt
cannot resolve then, since it fetches as the _apt user. Same template, same
pct, different umask. The reporter demonstrated it themselves: prefixing the
script with `umask 022` made the network problem go away.
That does make it ours to fix, whatever PegaProx does. A container should not
come out differently depending on the shell the script was launched from.
Scoped to the eight pct create calls rather than set for the whole build, so
the operator's umask still governs the logs and temp files we write on the
host -- narrowing their hardening beyond the one call that needs it would be
presumptuous.
The Incus path is deliberately untouched: incus launch hands the work to the
daemon, which extracts under its own umask, so the caller's never applied.
Wrapper checked for all three properties: 022 during the call, the previous
umask restored after, exit code passed through unchanged.
0 commit comments