* [pve-devel] [PATCH container] oci create: fix creating privileged containers
@ 2025-11-25 14:19 Filip Schauer
2025-11-26 8:31 ` Fabian Grünbichler
0 siblings, 1 reply; 4+ messages in thread
From: Filip Schauer @ 2025-11-25 14:19 UTC (permalink / raw)
To: pve-devel
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 <f.schauer@proxmox.com>
---
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [pve-devel] [PATCH container] oci create: fix creating privileged containers
2025-11-25 14:19 [pve-devel] [PATCH container] oci create: fix creating privileged containers Filip Schauer
@ 2025-11-26 8:31 ` Fabian Grünbichler
2025-11-26 8:55 ` Thomas Lamprecht
0 siblings, 1 reply; 4+ messages in thread
From: Fabian Grünbichler @ 2025-11-26 8:31 UTC (permalink / raw)
To: Proxmox VE development discussion
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 <f.schauer@proxmox.com>
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [pve-devel] [PATCH container] oci create: fix creating privileged containers
2025-11-26 8:31 ` Fabian Grünbichler
@ 2025-11-26 8:55 ` Thomas Lamprecht
2025-11-26 8:59 ` Thomas Lamprecht
0 siblings, 1 reply; 4+ messages in thread
From: Thomas Lamprecht @ 2025-11-26 8:55 UTC (permalink / raw)
To: Proxmox VE development discussion, Fabian Grünbichler
Am 26.11.25 um 09:31 schrieb Fabian Grünbichler:
> 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 <f.schauer@proxmox.com>
> or we could forbid creating them, since we want to get rid of privileged
> containers mid-to-longterm anyway?
Yeah, I had a similar reply as draft here. If it never worked at all for OCI,
that might be indeed the better route. It might be better to put your energy
into improving the UX for unprivileged CTs (uid shifts, bind mounts, ...?)
so that any still existing need (or simply less friction) for using privileged
ones goes away. As with that we could indeed start sunsetting them with PVE 10
(e.g. remove from UI in that version, then in PVE 11 from the create API, only
allowing to run pre-existing CTs).
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [pve-devel] [PATCH container] oci create: fix creating privileged containers
2025-11-26 8:55 ` Thomas Lamprecht
@ 2025-11-26 8:59 ` Thomas Lamprecht
0 siblings, 0 replies; 4+ messages in thread
From: Thomas Lamprecht @ 2025-11-26 8:59 UTC (permalink / raw)
To: Proxmox VE development discussion, Fabian Grünbichler,
Filip Schauer
Am 26.11.25 um 09:54 schrieb Thomas Lamprecht:
> Am 26.11.25 um 09:31 schrieb Fabian Grünbichler:
>> 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 <f.schauer@proxmox.com>
>> or we could forbid creating them, since we want to get rid of privileged
>> containers mid-to-longterm anyway?
>
> Yeah, I had a similar reply as draft here. If it never worked at all for OCI,
> that might be indeed the better route. It might be better to put your energy
(your = Filip)
> into improving the UX for unprivileged CTs (uid shifts, bind mounts, ...?)
> so that any still existing need (or simply less friction) for using privileged
> ones goes away. As with that we could indeed start sunsetting them with PVE 10
> (e.g. remove from UI in that version, then in PVE 11 from the create API, only
> allowing to run pre-existing CTs).
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-11-26 8:59 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-11-25 14:19 [pve-devel] [PATCH container] oci create: fix creating privileged containers Filip Schauer
2025-11-26 8:31 ` Fabian Grünbichler
2025-11-26 8:55 ` Thomas Lamprecht
2025-11-26 8:59 ` Thomas Lamprecht
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.