> Fiona Ebner <f.eb...@proxmox.com> hat am 12.09.2024 15:38 CEST geschrieben:
>
> Am 12.09.24 um 14:43 schrieb Fabian Grünbichler:
> > On August 13, 2024 3:28 pm, Fiona Ebner wrote:
> >> + $info->{'firewall-config'} = $firewall_file if -e $firewall_file;
> >> + $info->{'bandwidth-limit'} = $opts->{bwlimit} * 1024 if
> >> $opts->{bwlimit};
> >> + $backup_provider->backup_container($vmid, $config_file, $id_map,
> >> $findexcl, $info);
> >
> > it might be easier to hide the idmapping from the backup provider? e.g.,
> > hand it a idmapped bindmount or something like that?
> >
>
> Yes, that would be nicer. But could that potentially lead to permission
> issues? A mid/long term plan is to have the backup provider code run
> with lower privileges. I suppose to later implement that, the subroutine
> for the provider could run within a matching user namespace too?
yeah, I think there are a few options here
- run the provider as root-in-user-ns, give it access to the mapped FS (this is
how we do regular backups, but requires some glue code/forking)
- run the provider as root-on-host, give it access to a reverse-mapped FS
somehow (well, it would be nicer to run the backup code in the userns instead
of as root)
- run the provider as root-on-host, give it access to the mapped FS and let it
handle the (un)mapping itself (if they are not familiar with namespaces, this
might go wrong)
so if we find a generic way to do the first variant, we are both closer to how
we do backups, and err on the side of caution w.r.t. context of execution.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
