Thanks for feedback! I have tried to incorporate this on our wiki: https://cwiki.apache.org/confluence/display/GEODE/Finer+grained+security. Comments welcome.
On Thu, Apr 27, 2017 at 1:33 PM John Blum <jb...@pivotal.io> wrote: > +1 to Jake's comments, and is a fundamental property of Java's security > internally. > > On Thu, Apr 27, 2017 at 1:09 PM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > > > Typical solution to the X service needs to create something it service Y > > where user has permission to X but not to Y is to treat the actions on Y > > performed by X to be trusted. Often I have seen this implemented such > that > > after asserting permission on "create" on X that X performs actions on Y > as > > a trusted principal, like a "SYSTEM" user. The other option is to give > each > > service a trusted account and elevate to "SERVICE-X" where Y would allow > > "SERVICE-X" to perform some set of operations. > > > > See > > https://docs.oracle.com/javase/7/docs/api/javax/ > > security/auth/Subject.html#doAs(javax.security.auth. > > Subject,%20java.security.PrivilegedAction > > ) > > > > -Jake > > > > > > On Thu, Apr 27, 2017 at 11:28 AM Michael Stolz <mst...@pivotal.io> > wrote: > > > > > We have seen users who need per-Region permission for Data read/write, > so > > > there is precedent there at least. > > > > > > -- > > > Mike Stolz > > > Principal Engineer, GemFire Product Manager > > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771> > > > > > > On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra < > > pulkit.chan...@gmail.com> > > > wrote: > > > > > > > For per instance permission, I would say look for the evidence. Do we > > > have > > > > evidence that customers want per instance permission? If not may be > > > > implement minimally in the first cut and validate with customers if > > they > > > > want per instance model? > > > > > > > > About Lucene concern, It is in fact good to provide permission for > per > > > > logical operation that implementation is doing. This will align the > > > > security permission with operations performed and provide better > design > > > of > > > > a role. I would argue if you are able to perform 2 logically separate > > > > operations with single permission is perhaps a smell that you might > not > > > > have enough permissions. > > > > > > > > my $0.02 > > > > > > > > On Wed, 26 Apr 2017 at 16:54 Dan Smith <dsm...@pivotal.io> wrote: > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > -John > john.blum10101 (skype) >
