[Engine-devel] Disk Permissions Feature

[Einav Cohen]

> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo at redhat.com>
> Sent: Sunday, March 18, 2012 11:52:33 AM
> > > > 
> > > > On 03/15/2012 05:34 PM, Omer Frenkel wrote:
> > > > >>> >  >  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.
> > > > >
> > > > 
> > > > we can't require both quota and permissions from user on
> > > > storage
> > > > domains
> > > > - that's cumbersome.
> > > > question is if we can limit the need for permissions to disks
> > > > only
> > > > to
> > > > places where they are needed (shared, direct, floating)?
> > > +1 on that.
> > > I also think it is only relevant on attaching a disk to a VM, as
> > > the
> > > other use-cases are simpler:
> > > 1. Attach disk to VM - would require having permissions on the
> > > disk
> > > (whether it is shared, direct lun or floating)
> > > 2. Add disk to VM - would only require quota (if enforced).
> > > 3. Create disk (i.e., floating/shared disk) - would only require
> > > quota (if enforced).
> > 
> > and if not enforced? anyone can create as much disks as he like?
> > we thought of requiring permissions if quota is disabled,
> > but i think its confusing to the user as he plays with
> You are right. Need to think this through...
> Also, we need to get a better understanding on the use-cases for
> floating/shared disk... who is supposed to create them, and who to
> attach...

The convention today is that in order to create something, you need permissions on the ancestor entity.
Therefore, I think it should be as follows:

1. In order to create a Disk in a VM context, you need permission on the VM (just like in 3.0, IIRC).
2. In order to create a Floating Disk within a storage domain, you need permission on the storage domain
3. In order to create an External LUN Disk, you need permission on System/DC/Whatever we decide the ancestor entity of External LUN is.
4? Not sure regarding creation of External LUN Disk in a VM context (if that scenario exists) - will probably need a permission on both VM and External-LUN-ancestor, since this is a special case.

All of the above is regardless quota, meaning, if quota is enforced, quota restrictions will apply as relevant *in addition* to the permission limitations.

> 
> 
> > > 
> > > > _______________________________________________
> > > > 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
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>