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 wrote:
> +1 to Jake's comments, and is a fundamental property of Java's security
> internally.
+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 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
> perfor
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
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
On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra
wrote:
> For per instance permission, I would say look f
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 permi
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
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 affe
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 wrote:
> Think further, what about the team that a
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 wrote:
> +1
>
> I think it would also be a go
+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:MEMB
10 matches
Mail list logo
