[SOLVED] Permissions and Resource Pools

[Tom Moyer]

I have a resource pool and am trying to understand how permissions work for them. Suppose I have three users (student1, student2, and instructor) and two groups (students and instructors). Student1 and Student2 are members of the group students and instructor is a member of instructors. Ideally, I thought I could create a resource pool for the VMs and assign permissions to that resource pool in the following way.

@students -- NoAccess
@instructors -- PVEVMAdmin

And then in the individual VMs for each user, I could assign the following permissions:

Student1-VM -- student1@pve -- PVEVMUser
Student2-VM -- student2@pve -- PVEVMUser

And then when the student users login they would see only their own VM and the instructor would see all of the VMs assigned to that resource pool, but that doesn't seem to work. When a student logs in, they don't see anything. Am I missing something obvious in the assigning of permissions?

 

[fabian]

please provide your full acl.cfg..

 

[Tom Moyer]

please provide your full acl.cfg..

I didn't find an acl.cfg file, but I did find the ACLs in /etc/pve/user.cfg which I have posted below. If that isn't the right file, let me know and I can grab the right one. I recreated this in a test environment and there are 5 users. My expectation is the following, based on the pools and permissions I have tried to set. insturctor1 should be able to see containers 100 and 101. instructor2 should be able to see container 102. student1 should be able to see container 100. student2 should be able to see container 101. student3 should be able to see container 102. However, when I login as one of the students, I don't see anything. When I login as instructor1, I do see containers 100 and 101 as I expect. Does this mean that I should not be using the PVEVMUser role and instead using the PVEVMAdmin role, or something similar for the student accounts?

user:instructor1@pve:1:0::::::
user:instructor2@pve:1:0::::::
user:root@pam:1:0:::tom.moyer@uncc.edu:::
user:student1@pve:1:0::::::
user:student2@pve:1:0::::::
user:student3@pve:1:0::::::

group:class1-instructors:instructor1@pve::
group:class1-students:student1@pve,student2@pve::
group:class2-instructors:instructor2@pve::
group:class2-students:student3@pve::

pool:class1::100,101::
pool:class2::102::


acl:1:/pool/class1:@class1-students,@class2-instructors,@class2-students:NoAccess:
acl:1:/pool/class1:@class1-instructors:PVEVMAdmin:
acl:1:/pool/class2:@class1-instructors,@class1-students,@class2-students:NoAccess:
acl:1:/pool/class2:@class2-instructors:PVEVMAdmin:
acl:1:/vms/100:student1@pve:PVEVMUser:
acl:1:/vms/101:student2@pve:PVEVMUser:
acl:1:/vms/102:student3@pve:PVEVMUser:

 

[fabian]

sorry, yes, that is the correct file.

you don't need to specify NoAccess explicitly unless you define an ACL on a parent path with propagate set that you want to overrule. so if your student accounts don't have any other ACLs defined, just giving them PVEVMUser on their vm should be enough. similarly, for the instructor groups it should be enough to just give them PVEVMAdmin on their respective pools.

the problem is that NoAccess overwrites other privileges on the same ACL path. so if the user student1@pve has both NoAccess and PVEVMUser on /vms/100, the effective role will be NoAccess. pools are expanded first to /vms/XXX and /storage/YYY ACLs, so the NoAccess from the pool ACL will win over the explicit role for the /vms/XXX path.