From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 7B1F51FF179 for ; Wed, 26 Nov 2025 09:32:11 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 550B326725; Wed, 26 Nov 2025 09:32:22 +0100 (CET) Date: Wed, 26 Nov 2025 09:31:44 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20251125141922.165771-1-f.schauer@proxmox.com> In-Reply-To: <20251125141922.165771-1-f.schauer@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.17.0 (https://github.com/astroidmail/astroid) Message-Id: <1764145853.pp0ipj03q9.astroid@yuna.none> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1764145871506 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.045 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com, create.pm] Subject: Re: [pve-devel] [PATCH container] oci create: fix creating privileged containers X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On November 25, 2025 3:19 pm, Filip Schauer wrote: > Previously, creating privileged containers from OCI images failed with: > `unable to create CT 123 - Invalid argument` > > This was caused by an empty $id_map being passed to run_in_userns. > > This commit fixes this by making the call to run_in_userns conditional, > based on whether $id_map is empty or not. > > Reported in the Proxmox forum: > https://forum.proxmox.com/threads/proxmox-virtual-environment-9-1-available.176255/post-818600 > > Signed-off-by: Filip Schauer or we could forbid creating them, since we want to get rid of privileged containers mid-to-longterm anyway? > --- > src/PVE/LXC/Create.pm | 47 +++++++++++++++++++++++++------------------ > 1 file changed, 27 insertions(+), 20 deletions(-) > > diff --git a/src/PVE/LXC/Create.pm b/src/PVE/LXC/Create.pm > index dc97327..9956cf9 100644 > --- a/src/PVE/LXC/Create.pm > +++ b/src/PVE/LXC/Create.pm > @@ -674,12 +674,17 @@ sub restore_oci_archive { > > my ($id_map, undef, undef) = PVE::LXC::parse_id_maps($conf); > # NOTE: values of $unsafe_oci_config are untrusted! do NOT use them as is, only via the helpers! > - my $unsafe_oci_config = PVE::LXC::Namespaces::run_in_userns( > - sub { > - PVE::RS::OCI::parse_and_extract_image($archive_file, $rootdir); > - }, > - $id_map, > - ); > + my $unsafe_oci_config; > + if (@$id_map) { > + $unsafe_oci_config = PVE::LXC::Namespaces::run_in_userns( > + sub { > + PVE::RS::OCI::parse_and_extract_image($archive_file, $rootdir); > + }, > + $id_map, > + ); > + } else { > + $unsafe_oci_config = PVE::RS::OCI::parse_and_extract_image($archive_file, $rootdir); > + } > > # should we rather validate this on the rust side already? > my $has_ctrl_char = sub { return $_[0] =~ /[\x00-\x08\x10-\x1F\x7F]/; }; > @@ -715,20 +720,22 @@ sub restore_oci_archive { > # This will also keep the cases working where a user does know about them and > # added MPs at this locations, at they will simply get mounted there correctly then. > # TODO: should the folders always be owned by the CT root user though? > - PVE::LXC::Namespaces::run_in_userns( > - sub { > - # we're now in the correct user namespace, but not in the mount namespace, so chroot > - # into the rootdir to ensure that make_path is safe from ../ and symlinks! > - chroot($rootdir) or die "failed to change root to: $rootdir: $!\n"; > - chdir('/') or die "failed to change to root directory\n"; > - > - for my $path (@data_volume_paths) { > - print "creating base directory for volume at $path\n"; > - make_path("/$path"); # chrooted to /$rootdir above already > - } > - }, > - $id_map, > - ); > + my $create_volume_paths = sub { > + # we're not in the correct mount namespace, so chroot into the rootdir > + # to ensure that make_path is safe from ../ and symlinks! > + chroot($rootdir) or die "failed to change root to: $rootdir: $!\n"; > + chdir('/') or die "failed to change to root directory\n"; > + > + for my $path (@data_volume_paths) { > + print "creating base directory for volume at $path\n"; > + make_path("/$path"); # chrooted to /$rootdir above already > + } > + }; > + if (@$id_map) { > + PVE::LXC::Namespaces::run_in_userns($create_volume_paths, $id_map); > + } else { > + PVE::Tools::run_fork($create_volume_paths); > + } > } > > my $init_cmd = []; > -- > 2.47.3 > > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel