Am 13.09.24 um 08:19 schrieb Fabian Grünbichler:
>> 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)
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.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
