Backup access for users results in Permission check failed (/storage/null, Datastore.Audit(Datastore.AllocateSpace) (403)

[riedel]

Hi,

Despite the User having Datastore.Audit and Datastore.AllocateSpace rights (on the VM and the Pool via the appropriate PVE roles) , we have the problem that we are not able to allow users to do a backup.

The backup tab is present but the user gets

Backup access for users results in Permission check failed (/storage/null, Datastore.Audit(Datastore.AllocateSpace) (403)

and the storage is not shown in the dropdown at the top

I am suspecting that we also have to give permissions to the appropriate storage called (I guess "/storage/null" is the null value in the UI ). Which is called "backup" and is a Proxmox Backup Server.

Is this possible?

Can it be configured, that only the backups of a user VM are accessible?

At the moment our users always have to write admin tickets to get both a backup schedule and the backup restored.

Many thanks in advance

Till

 

[riedel]

The current permissions are managed mostly on pool level, we had:

VM.Console, VM.Clone, Pool.Audit, VM.Config.Options, VM.Config.CDROM, VM.Monitor, Pool.Allocate, VM.Config.Disk, VM.Snapshot, VM.PowerMgmt, VM.Allocate, VM.Snapshot.Rollback, VM.Config.Cloudinit, VM.Audit, Datastore.Allocate, Datastore.AllocateSpace, Datastore.AllocateTemplate, Datastore.Audit, Group.Allocate, Permissions.Modify, Realm.Allocate, Realm.AllocateUser, SDN.Allocate, SDN.Audit, Sys.Audit, Sys.Console, Sys.Incoming, Sys.Modify, Sys.PowerMgmt, Sys.Syslog, User.Modify,  VM.Config.CPU, VM.Config.HWType, VM.Config.Memory, VM.Config.Network, VM.Migrate

and I added

VM.Backup, Datastore.AllocateSpace , Datastore.Audit

but I still got the error above.

 

[ViennaTux]

Hi, we ran into the same problem.
Just add under "Permissions" the path "/storage" for the user or group and it works...

 

[fabian]

could you please give a clear description of your ACL setup that triggers the error? (ideally the full user.cfg, you can censor sensitive information but please do so in a manner that preserves the contents, e.g., always replace a username X with the same string)

 

[ViennaTux]

user.cfg:

user:ab@CUSTDOMAIN:1:0:AAA:BBB:a.b@CUSTDOMAIN.TLD:::
user:cd@CUSTDOMAIN:1:0:CCC:DDD:c.d@CUSTDOMAIN.TLD:::
user:ef@CUSTDOMAIN:1:0:EEE:FFF:e.f@CUSTDOMAIN.TLD:::
user:gh@CUSTDOMAIN:1:0:GGG:HHH:g.h@@CUSTDOMAIN.TLD:::
user:root@pam:1:0:::ME@HOME:::

group:CUSTVMAdmins:ab@CUSTDOMAIN,cd@CUSTOMAIN,ef@CUSTDOMAIN::
group:AdminUsers:ef@CUSTOMAIN::
group:Users:gh@CUSTDOMAIN::


role:CUSTVMAdm:Datastore.AllocateSpace,Datastore.Audit,VM.Audit,VM.Backup,VM.Console,VM.PowerMgmt,VM.Sna
pshot,VM.Snapshot.Rollback:
role:Auditor:Datastore.Audit,SDN.Audit,Sys.Audit,VM.Audit:

acl:1:/vms/3054:@CUSTVMAdmins:ARCVMAdm:
acl:1:/vms/1905:@CUSTVMAdmins:ARCVMAdm:
acl:1:/vms/4005:cd@CUSTDOMAIN,ef@CUSTDOMAIN:CUSTVMAdm:
acl:1:/vms/4004:cd@CUSTDOMAINef@CUSTDOMAIN,:CUSTVMAdm:
acl:1:/vms/1057:@CUSTVMAdmins:CUSTVMAdm:
acl:1:/storage:@CUSTVMAdmins:CUSTVMAdm:

Do you need more info?

 

[ViennaTux]

adendum:
right before the last update everything worked without the "/storage" path...

 

[fabian]

creating a backup has always required write access to the backup target storage.. the error message could probably be better though!

 

[fabian]

filed https://bugzilla.proxmox.com/show_bug.cgi?id=4840 for improving the error message.

 

[ViennaTux]

Hi Fabian,
the only thing different from about a week ago ist the path entry.
And thanks for the attemt to improve the error message

 

[fabian]

which package versions were involved in the upgrade? (/var/log/apt/history.log should tell you)

 

[ViennaTux]

The last update on June 28 included:

Start-Date: 2023-06-28  13:20:36
Commandline: apt-get --no-install-recommends -o Dpkg::Options::=--force-confnew install -- ceph ceph-common ceph-mds ceph-fuse gdisk
nvme-cli ceph-volume
Install: python3-paste:amd64 (3.5.0+dfsg1-1, automatic), python3-webtest:amd64 (2.0.35-1, automatic), ceph-volume:amd64 (17.2.6-pve1)
, python3-dateutil:amd64 (2.8.1-6, automatic), libfmt7:amd64 (7.1.3+ds1-5, automatic), ceph-mgr-modules-core:amd64 (17.2.6-pve1, auto
matic), python3-cherrypy3:amd64 (8.9.1-8, automatic), cryptsetup-bin:amd64 (2:2.3.7-1+deb11u1, automatic), python3-cffi-backend:amd64
(1.14.5-1, automatic), libthrift-0.13.0:amd64 (0.13.0-6, automatic), libqt5core5a:amd64 (5.15.2+dfsg-9, automatic), python3-lib2to3:
amd64 (3.9.2-1, automatic), ceph-base:amd64 (17.2.6-pve1, automatic), python3-ceph-common:amd64 (17.2.6-pve1, automatic), librgw2:amd
64 (17.2.6-pve1, automatic), python3-waitress:amd64 (1.4.4-1.1+deb11u1, automatic), python3-logutils:amd64 (0.3.3-7, automatic), libq
t5network5:amd64 (5.15.2+dfsg-9, automatic), libqt5dbus5:amd64 (5.15.2+dfsg-9, automatic), libdouble-conversion3:amd64 (3.1.5-6.1, au
tomatic), python3-werkzeug:amd64 (1.0.1+dfsg1-2, automatic), nvme-cli:amd64 (1.12-5), shared-mime-info:amd64 (2.0-1, automatic), pyth
on-pastedeploy-tpl:amd64 (2.1.1-1, automatic), librdkafka1:amd64 (1.6.0-1, automatic), ceph-mds:amd64 (17.2.6-pve1), ceph-mgr:amd64 (
17.2.6-pve1, automatic), ceph-mon:amd64 (17.2.6-pve1, automatic), ceph-osd:amd64 (17.2.6-pve1, automatic), libpcre2-16-0:amd64 (10.36
-2+deb11u1, automatic), python3-openssl:amd64 (20.0.1-1, automatic), python3-mako:amd64 (1.1.3+ds1-2, automatic), python3-soupsieve:a
md64 (2.2.1-1, automatic), uuid-runtime:amd64 (2.36.1-8+deb11u1, automatic), python3-natsort:amd64 (7.1.0-1, automatic), python3-bs4:
amd64 (4.9.3-1, automatic), python3-simplegeneric:amd64 (0.8.1-3, automatic), python3-markupsafe:amd64 (1.1.1-1+b3, automatic), pytho
n3-pecan:amd64 (1.3.3-3, automatic), python3-singledispatch:amd64 (3.4.0.3-3, automatic), python3-pastedeploy:amd64 (2.1.1-1, automat
ic), python3-rgw:amd64 (17.2.6-pve1, automatic), python3-yaml:amd64 (5.3.1-5, automatic), ceph:amd64 (17.2.6-pve1), sudo:amd64 (1.9.5
p2-3+deb11u1, automatic), python3-distutils:amd64 (3.9.2-1, automatic), python3-bcrypt:amd64 (3.1.7-4, automatic), python3-webob:amd6
4 (1:1.8.6-1.1, automatic), python3-cryptography:amd64 (3.3.2-1, automatic), libsqlite3-mod-ceph:amd64 (17.2.6-pve1, automatic), libl
ttng-ust-ctl4:amd64 (2.12.1-1, automatic), python3-tempita:amd64 (0.5.2-6, automatic), liblttng-ust0:amd64 (2.12.1-1, automatic)
Upgrade: librados2:amd64 (14.2.21-1, 17.2.6-pve1), ceph-fuse:amd64 (14.2.21-1, 17.2.6-pve1), librbd1:amd64 (14.2.21-1, 17.2.6-pve1),
ceph-common:amd64 (14.2.21-1, 17.2.6-pve1), python3-cephfs:amd64 (14.2.21-1, 17.2.6-pve1), libcephfs2:amd64 (14.2.21-1, 17.2.6-pve1),
libradosstriper1:amd64 (14.2.21-1, 17.2.6-pve1), python3-rbd:amd64 (14.2.21-1, 17.2.6-pve1), python3-ceph-argparse:amd64 (14.2.21-1,
17.2.6-pve1), python3-rados:amd64 (14.2.21-1, 17.2.6-pve1)
End-Date: 2023-06-28  13:20:58

Up until then the user had access to the storages...

 

[fabian]

that seems very unlikely, since that set of packages doesn't involve anything that relates to the PVE code..

the checks for storage access have also been there for ages - maybe you modified the ACLs together with the ceph installation?

 

[fabian]

@riedel could you maybe also provide your (broken) user.cfg contents? thanks!

 

[ViennaTux]

that seems very unlikely, since that set of packages doesn't involve anything that relates to the PVE code..

the checks for storage access have also been there for ages - maybe you modified the ACLs together with the ceph installation?

not knowingly, as only I am working on these kinds of settings.

 

[ViennaTux]

@riedel could you maybe also provide your (broken) user.cfg contents? thanks!

the user.cfg before and after differed only in these lines:

acl:1:/vms/4005:cd@CUSTDOMAIN,ef@CUSTDOMAIN:CUSTVMAdm:
acl:1:/storage:@CUSTVMAdmins:CUSTVMAdm:

(I checked agains the version from June 15)

 

[riedel]

Hi,

thanks to your hint: I made it work by adding

acl:1:/storage/backup:@Staff:PVEDatastoreUser:

As already discussed: the error seemed weird, and I could actually not find the storage permissions in the UI.

I am now, however, wondering if I did it correctly, or if I should rather add backup to all the pools as this also exposes the permissions correctly via the UI

pool:name::115,121,132:backup:
acl:1:/pool/edgeml:user@ldap:PVEVMAdmin,TECOPoolAdmin,PVEDatastoreUser:

Best

Till

PS:Sorry for the late reply. There was vacation and the problem only popped up now again.

 

[fabian]

I assume user@ldap is in your @staff group? if so, the difference between adding it to the pool ACL or on its own is just whether the other users in @staff get it as well.. (and that going via the pool means the privs of that role are also set on the VM paths, but that has no effect)

 

[fortechitsolutions]

Hi, I am curious, I am gently banging my head on this same topic today, ~a year later (Aug.2024) and I'm curious if there is a way to do this so it works, via the webUI admin interface only? my scenario, is that I'm trying to grant one person admin access onto a single VM on a single proxmox host. So that this person can make/restore/delete backups of the VM. Right now his user exists as a HisName@pve local PVE (only) auth, and I've granted him (Initially) "Administrator" rights on the VM in question; this resulted in the error being returned "Permission check failed (/storage/null, Datastore.Audit(Datastore.AllocateSpace) (403)" when his user is signed in to webUI, can see the VM and then tries to go into 'backup' tab for that VM. Then I tried adding rights = PVEDataStoreAdmin and also PVEDataStoreUser - and the error persists, he can't touch the backups. The proxmox host is running proxmox 8.0.3 / standalone not cluster / local storage and PBS storage on a different dedicated PBS Box for backups.

Thank you!
Tim

 

[fabian]

on which paths did you give out the storage related roles? could you post the output of a permission dump for that user (UI or via pveum)?

 

[fortechitsolutions]

Hi, thank you Fabian for the reply! I think I may have figured out - let me know your thought? In attempting to set this up I allocated permission onto a single VM specifically (only) for the user being setup. I only just now added a similar permission control onto the PBS datastore shown in proxmox to specifically grant this same user the role "pveDataStoreAdmin" and now things work. arguably this is a imperfect setup because in perfect world I would allow this user only to see backups in the PBS storage related to the VM for which he is entiled to manage. But I am not clear there is way to get that granularity in the PBS datastore permission granting process (?)