I agree that async event queues seem like a different case than wan or disk. In that case you are not using anything that creating a region doesn't do.
Shouldn't creating a region be DATA:MANAGE:DISK? Requiring DATA privileges for a region without disk and CLUSTER privileges for a region with disk seems weird. Same issues with creating a region that uses WAN. -Dan On Wed, Apr 26, 2017 at 12:53 PM, Diane Rose Hardman <dhard...@pivotal.io> wrote: > One more possible complication is that creating a Lucene index will also > create an AsyncEventQueue. Today the required permission to create the AEQ > is DATA:MANAGE which coincidentally nicely matches the permission required > to create an OQL index. > Pulling out the AEQ as a separate resource will affect Lucene index > creation. FYI. > > On Tue, Apr 25, 2017 at 3:10 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > DATA:*:RegionA would allow you to only operate that region but not all of > > them. > > > > if we want to control a specific wan, maybe we add a fourth parameter: > > cluster:*:wan:wanName, same goes for Disk etc. > > > > On Tue, Apr 25, 2017 at 3:03 PM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > > > Think further, what about the team that ask that I be able to mange a > > > region not all regions, or a wan not all wan. It may be time to think > > about > > > a full per instance / > > > named resource based security model. > > > > > > On Tue, Apr 25, 2017 at 2:59 PM Jared Stewart <jstew...@pivotal.io> > > wrote: > > > > > > > +1 > > > > > > > > I think it would also be a good idea to move the current operations > > > > permitted by CLUSTER:MANAGE ( stop server, alter runtime, etc) to > > require > > > > the more specific CLUSTER:MANAGE:MEMBER in order to avoid ambiguity. > > > (This > > > > is not a breaking change since CLUSTER:MANAGE implies > > > > CLUSTER:MANAGE:MEMBER.) > > > > > > > > > On Apr 25, 2017, at 2:48 PM, Swapnil Bawaskar < > sbawas...@pivotal.io> > > > > wrote: > > > > > > > > > > In our current security model, a user with DATA:MANAGE can create > > > > regions, > > > > > create disk stores, WAN gateways etc. I think this is a very wide > > > scope, > > > > > because an administrator may want to give create region privilege > to > > a > > > > > developer, but not necessarily give them the ability to create disk > > > > stores > > > > > or send the data in that region over WAN. I propose that we refine > > the > > > > > security model to make it finer grained. > > > > > > > > > > I propose that Disk, WAN and AsyncQueue be treated as resources in > > the > > > > > security framework. These resources will be controlled at the > CLUSTER > > > > > level. As with any other resource, admins will be able to grant > READ, > > > > WRITE > > > > > and MANAGE permissions to these resources. In terms of shiro, this > > will > > > > > take the form: CLUSTER:READ/WRITE/MANAGE:DISK,WAN,ASYNCQUEUE. > > > > > > > > > > Here is how it will work out for each resource: > > > > > DISK > > > > > 1. CLUSTER:MANAGE:DISK - allows users to create/manage disk stores > > > > > 2. CLUSTER:WRITE:DISK - allows users to create regions that > > > > write/overflow > > > > > to disk stores > > > > > 3. CLUSTER:READ:DISK - should be covered by DATA:READ, does not > make > > > > sense > > > > > here > > > > > > > > > > WAN: > > > > > 1. CLUSTER:MANAGE:WAN - allows users to create gateway senders and > > > > receivers > > > > > 2. CLUSTER:WRITE:WAN - allows users to create regions that write > data > > > to > > > > > gateway senders > > > > > 3. CLUSTER:READ:WAN - allows users to create regions that read data > > > from > > > > > gateway receivers > > > > > > > > > > We can add other things like functions here as well. > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > >
