[Engine-devel] Disk Permissions Feature

Omer Frenkel ofrenkel at redhat.com
Thu Mar 15 15:34:58 UTC 2012



----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Itamar Heim" <iheim at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, March 15, 2012 9:52:59 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
> 
> On 15/03/12 07:25, Itamar Heim wrote:
> > On 03/14/2012 02:20 AM, Moti Asayag wrote:
> >> Hi all,
> >>
> >> Disk Permissions feature description Wiki page:
> >> http://www.ovirt.org/wiki/Features/DiskPermissions
> >>
> >> Please share your comments.
> > 
> > I think you are lacking a paragraph explaining some of the issues
> > around
> > this:
> > - are disks part of storage domains or VMs wrt permissions
> > inheritance?

yes - "Disk inherits permissions from the VM it is attached to and from the storage domain it resides on (if there is one)"

> > - what about direct luns (are not part of storage domains)?
> > - what about shared disks (multiple inheritance if from VM)?

i guess so, i think current vm roles shouldn't contain the disks actions,
therefore vm admin cannot change any disk attached to his vm,
only if got an explicit permission on it.
(one can have "disk-operator" on vm, and then can manipulate any disk related to that vm)

> > - what if tomorrow we allow disks to span multiple storage domains?

i don't see a problem with this, as user will need to have permission on all the domains,
makes sense to me.

> > - quota's are already a concept of permissions to create disks at
> > storage domain level, does user need both (cumbersome)
> > - when do we must have this (to filter shared, floating or direct
> > lun
> > disks we would show to power users when not attached to VMs) - or
> > these
> > won't be available for now via the power user portal, only via
> > admin.
> > 
> > 1. "Create disk - requires permissions on the Storage Domain,
> > (can't
> > assume Quota is sufficient to permit user creating the disk on the
> > Storage Domain, as Quota might be disabled)"
> > 
> > I'd also specify create disk for regular disks is at storage domain
> > level?, while direct lun disks require system level permission of
> > add disk.
> > 
> > so, if quota is disabled, how important is it to prevent creation
> > of
> > disks (other than direct lun ones, which would require a permission
> > similar to storage domain creation)?
> > 
> > if this is added, it has to be implicitly added / not needed if
> > user has
> > quota (i.e., having a quota should be similar to having a
> > permission as
> > far as the check goes).
> > 
> 
> We should look into it, how complicate is it to validate if user has
> either quota or permission, and allow creating a disk on a SD if
> either
> exists.

this might be confusing to the user as he can disable the quota,
then stuff would stop working.

> 
> > 2. "Attach disk to VM - requires permissions on the Disk and on the
> > VM
> > (applies for shared disk as well). "
> > 
> > which permission at disk is required? (disk access?)
> > 
> 
> 
> The user should have attach_disk permission on the disk and on the VM
> (same action on two objects).
> 
> > 3. "Detach disk from VM - requires permissions on the VM only.
> > (Unlike
> > 
> > attach disk that requires permissions on the VM and on the Disk). "
> > 
> > will detaching a disk copy the permission it so far inherited from
> > the VM?
> > 
> 
> No, inheritance is never translated into explicit permission on the
> objects in the hierarchy .
> 
> > 4. UI changes
> > an edit permissions button from VM disks subtab seems appropriate
> > (will
> > open a dialog i guess)
> 
> I think we need permissions subtab in the floating disk main tab.
> I'll ask Einav to add the UI part as well to the wiki.
> 
> 
> 
> > ________________________
> _______________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



More information about the Engine-devel mailing list