Re: [Engine-devel] Disk Permissions Feature

From: "Einav Cohen" <ecohen(a)redhat.com&gt; To: "Oved Ourfalli" <ovedo(a)redhat.com&gt; 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&gt; > 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 > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel