[pve-devel] [RFC container v2 22/25] backup: implement backup for external providers

[Fiona Ebner]

Am 13.09.24 um 08:19 schrieb Fabian Grünbichler:
>> Fiona Ebner <f.ebner at 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)

Gave this a try. Issue is that the backup provider also needs access to
the backup target/etc. Can network access also be an issue (I guess it
is not for PBS)?

E.g. directory example plugin fails with
> ERROR: Backup of VM 112 failed - unable to open file '/mnt/pve/sparschwein/112/lxc-1726484790/guest.conf.tmp.125275' - Permission denied
and Borg plugin fails with
> ERROR: Backup of VM 112 failed - mkdir /run/pve-storage-borg-plugin: Permission denied at /usr/share/perl5/PVE/BackupProvider/Plugin/Borg.pm line 41
or after switching to /tmp with
> ERROR: Backup of VM 112 failed - file '/etc/pve/priv/storage/borg.pw' exists but open for reading failed - Permission denied

Less coupling with the associated storage plugin or a special kind of
"unprivileged" storage plugin would help. In PBS we do the
storage-plugin-related stuff first with root privileges and only run the
final pbs-client command in user namespace. Maybe we need something like
that here too, a preparatory method run as root that prepares for the
unprivileged backup operation? But that makes life more complicated for
provider implementers (and also us).

> - 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)

I'd try and go with this option for now if that is okay.

> - 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.