7:20 p.m.
Hi all,
Disk Permissions feature description Wiki page:
http://www.ovirt.org/wiki/Features/DiskPermissions
Please share your comments.
Thanks,
Moti
2:22 a.m.
On 14/03/12 02:20, Moti Asayag wrote:
Hi all,
Disk Permissions feature description Wiki page:
http://www.ovirt.org/wiki/Features/DiskPermissions
Please share your comments.
I changed the wiki to use the terminology we used previously when
discussing permissions.
I also fixed some things, for example AddDiskToVM I changed the need for
permissions on the disk to need permissions on the storage domain.
I am missing details of what actions does the DISK_OPERATOR role
includes, also when a user creates a disk what permissions do we give
him implicitly (DISK_OPERATOR ?)
The upgrade flow is written in the open issues, we need to move it from
the open issues to it's own section and add there that all disk related
operations should be added to the system administrator.
The direct LUN open issues are mostly because the implementation is not
there yet, it is not about the behavior of the permissions AFAIU.
Thanks, Livnat
Thanks,
Moti
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:37 a.m.
On 03/14/2012 09:22 AM, Livnat Peer wrote:
On 14/03/12 02:20, Moti Asayag wrote:
> Hi all,
>
> Disk Permissions feature description Wiki page:
> http://www.ovirt.org/wiki/Features/DiskPermissions
>
> Please share your comments.
>
I changed the wiki to use the terminology we used previously when
discussing permissions.
I also fixed some things, for example AddDiskToVM I changed the need for
permissions on the disk to need permissions on the storage domain.
I am missing details of what actions does the DISK_OPERATOR role
includes, also when a user creates a disk what permissions do we give
him implicitly (DISK_OPERATOR ?)
Added to wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Roles
The upgrade flow is written in the open issues, we need to move it from
the open issues to it's own section and add there that all disk related
operations should be added to the system administrator.
Added to wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Upgrade_DB
The direct LUN open issues are mostly because the implementation is not
there yet, it is not about the behavior of the permissions AFAIU.
Indeed.
Thanks, Livnat
> Thanks,
> Moti
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
12:25 a.m.
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?
- what about direct luns (are not part of storage domains)?
- what about shared disks (multiple inheritance if from VM)?
- what if tomorrow we allow disks to span multiple storage domains?
- 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).
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?)
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?
4. UI changes
an edit permissions button from VM disks subtab seems appropriate (will
open a dialog i guess)
2:52 a.m.
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?
- what about direct luns (are not part of storage domains)?
- what about shared disks (multiple inheritance if from VM)?
- what if tomorrow we allow disks to span multiple storage domains?
- 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.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:34 a.m.
----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: engine-devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:46 a.m.
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)?
4:09 a.m.
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Omer Frenkel" <ofrenkel(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, March 15, 2012 5:46:07 PM
Subject: Re: [Engine-devel] Disk Permissions Feature
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).
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
4:27 a.m.
----- Original Message -----
From: "Oved Ourfalli" <ovedo(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Omer Frenkel" <ofrenkel(a)redhat.com>
Sent: Sunday, March 18, 2012 11:09:54 AM
Subject: Re: [Engine-devel] Disk Permissions Feature
----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Omer Frenkel" <ofrenkel(a)redhat.com>
> Cc: engine-devel(a)ovirt.org
> Sent: Thursday, March 15, 2012 5:46:07 PM
> Subject: Re: [Engine-devel] Disk Permissions Feature
>
> 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
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
4:52 a.m.
----- Original Message -----
From: "Omer Frenkel" <ofrenkel(a)redhat.com>
To: "Oved Ourfalli" <ovedo(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Sunday, March 18, 2012 11:27:33 AM
Subject: Re: [Engine-devel] Disk Permissions Feature
----- Original Message -----
> From: "Oved Ourfalli" <ovedo(a)redhat.com>
> To: "Itamar Heim" <iheim(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Omer Frenkel" <ofrenkel(a)redhat.com>
> Sent: Sunday, March 18, 2012 11:09:54 AM
> Subject: Re: [Engine-devel] Disk Permissions Feature
>
>
>
> ----- Original Message -----
> > From: "Itamar Heim" <iheim(a)redhat.com>
> > To: "Omer Frenkel" <ofrenkel(a)redhat.com>
> > Cc: engine-devel(a)ovirt.org
> > Sent: Thursday, March 15, 2012 5:46:07 PM
> > Subject: Re: [Engine-devel] Disk Permissions Feature
> >
> > 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...
>
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
3:25 a.m.
----- Original Message -----
From: "Oved Ourfalli" <ovedo(a)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(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
6:22 a.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Oved Ourfalli" <ovedo(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Monday, March 19, 2012 10:25:24 AM
Subject: Re: [Engine-devel] Disk Permissions Feature
> ----- Original Message -----
> From: "Oved Ourfalli" <ovedo(a)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
"1" is okay as long as we limit the user from detaching this disk later on, as
detaching it will make it floating.
Or, we can allow detaching only in case the user has permissions on the storage domain,
but that will be hard to understand in a user's perspective.
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(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > >
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:03 p.m.
On 03/15/2012 05:46 PM, Itamar Heim wrote:
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)?
Wiki is updated with a proposal for this issue. In a nutshell, adding
'automatic' permissions on the Storage Domain (or to Storage Pool for
Global quota) to relevant users when performing Quota specific actions
so they be used regardless quota concern (e.g. when Quota is disabled
for DC):
http://www.ovirt.org/wiki/Features/DiskPermissions#Design
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
5:47 a.m.
1.
According to the wiki, these are the new Action Groups that will be added:
CREATE_DISK - AddDisk, AddDiskToVm
EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate
ATTACH_DISK - AttachDiskToVm
CONFIGURE_DISK_STORAGE - MoveOrCopyDisk
DELETE_DISK - RemoveDisk, RemoveVm
Currently we have:
CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk
So, since "AddDiskToVm" has moved to "CREATE_DISK", it will now be:
CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk
- Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the
difference?
- Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the
difference?
[If answer to both questions is "no", CONFIGURE_VM_STORAGE action-group should
be removed; this should be considered in the upgrade process]
2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group
will "DetachDiskFromVm" reside?
3. "Updated Roles: VM Operator should be extended with permissions on Disk" -
note that all other pre-defined roles that have "UpdateVM" within them (and most
of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups
(otherwise we can reach strange situations in which a Cluster Admin can do everything in
his cluster except manipulate Disks in his VMs, for example).
4. "Upgrade DB: Add Disk Operator role to users that have VM Operators to allow
permissions on Disks":
- I assume that you mean that Disk Operator *permissions* should be added on the relevant
*Disks* to the "VM Operator" users.
- I suggest to add these during upgrade not only for "VM Operators" but for all
users that have a direct permission on a VM which is associated with any Role that
contains the action "UpdateVM".
5. GUI will need a new query: GetAllAttachableDisks.
- This query should be an Admin + User query and will have two "flavors": Admin
and User (using the "isFiltered" property).
- With "isFiltered = false" (will be used for the admin portal), it should
return a list of all floating and/or sharable disks.
- With "isFiltered = true" (will be used in the power user portal), it should
return a list of all floating and/or sharable disks on which the user has permissions.
----
Thanks,
Einav
----- Original Message -----
From: "Moti Asayag" <masayag(a)redhat.com>
To: engine-devel(a)ovirt.org
Sent: Wednesday, March 14, 2012 2:20:18 AM
Subject: [Engine-devel] Disk Permissions Feature
Hi all,
Disk Permissions feature description Wiki page:
http://www.ovirt.org/wiki/Features/DiskPermissions
Please share your comments.
Thanks,
Moti
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
11:55 a.m.
On 03/19/2012 12:47 PM, Einav Cohen wrote:
1.
According to the wiki, these are the new Action Groups that will be added:
CREATE_DISK - AddDisk, AddDiskToVm
EDIT_DISK_PROPERTIES - UpdateDisk, UpdateVM, Activate/Deactivate
ATTACH_DISK - AttachDiskToVm
CONFIGURE_DISK_STORAGE - MoveOrCopyDisk
DELETE_DISK - RemoveDisk, RemoveVm
Currently we have:
CONFIGURE_VM_STORAGE - AddDiskToVm, RemoveDisksFromVm, UpdateVmDisk
So, since "AddDiskToVm" has moved to "CREATE_DISK", it will now be:
CONFIGURE_VM_STORAGE - RemoveDisksFromVm, UpdateVmDisk
- Is there a difference between RemoveDisk and RemoveDisksFromVm? If so, what is the
difference?
- Is there a difference between UpdateDisk and UpdateVmDisk? If so, what is the
difference?
[If answer to both questions is "no", CONFIGURE_VM_STORAGE action-group should
be removed; this should be considered in the upgrade process]
This point should be taken into consideration when design/implementation
of new verbs (RemoveDisk / UpdateDisk ) is done.
2. [Michael/Daniel] (more related to the floating disks feature): In which Action Group
will "DetachDiskFromVm" reside?
3. "Updated Roles: VM Operator should be extended with permissions on Disk" -
note that all other pre-defined roles that have "UpdateVM" within them (and most
of them do, AFAIK) should also be extended with the extra Disk-related ActionGroups
(otherwise we can reach strange situations in which a Cluster Admin can do everything in
his cluster except manipulate Disks in his VMs, for example).
Updated wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Updated_Roles
4. "Upgrade DB: Add Disk Operator role to users that have VM Operators to allow
permissions on Disks":
- I assume that you mean that Disk Operator *permissions* should be added on the relevant
*Disks* to the "VM Operator" users.
- I suggest to add these during upgrade not only for "VM Operators" but for all
users that have a direct permission on a VM which is associated with any Role that
contains the action "UpdateVM".
Updated wiki:
http://www.ovirt.org/wiki/Features/DiskPermissions#Upgrade_DB
5. GUI will need a new query: GetAllAttachableDisks.
- This query should be an Admin + User query and will have two "flavors":
Admin and User (using the "isFiltered" property).
- With "isFiltered = false" (will be used for the admin portal), it should
return a list of all floating and/or sharable disks.
- With "isFiltered = true" (will be used in the power user portal), it should
return a list of all floating and/or sharable disks on which the user has permissions.
----
Thanks,
Einav
----- Original Message -----
> From: "Moti Asayag" <masayag(a)redhat.com>
> To: engine-devel(a)ovirt.org
> Sent: Wednesday, March 14, 2012 2:20:18 AM
> Subject: [Engine-devel] Disk Permissions Feature
>
> Hi all,
>
> Disk Permissions feature description Wiki page:
> http://www.ovirt.org/wiki/Features/DiskPermissions
>
> Please share your comments.
>
> Thanks,
> Moti
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
4418
days inactive
4423
days old
14 comments
6 participants
participants (6)
-
Einav Cohen -
Itamar Heim -
Livnat Peer -
Moti Asayag -
Omer Frenkel -
Oved Ourfalli