Re: [PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Juan José Ramos]

Hello Dave,

Thanks for the heads up, spelling errors fixed (at least that one :-/).
Cheers!.


On Mon, Jun 25, 2018 at 4:34 PM Dave Barnes  wrote:

> Juan,
> Nice work - you've obviously given this plenty of thought. I'm not
> qualified to comment on the technical aspects of your proposal, but as a
> proofreader I noticed that there are a couple of occurrences of
> "invokation" that should be spelled "invocation".
> Dave
>
>
>
> On Mon, Jun 25, 2018 at 2:52 AM, Ju@N  wrote:
>
> > Hello all,
> >
> > The current approach used to authorize methods during OQL execution seems
> > to be way too restrictive, I've drafted a proposal to change the current
> > behavior and allow further customization:
> > https://cwiki.apache.org/confluence/display/GEODE/
> > Customizable+Security+When+Invoking+Methods+in+OQL
> >
> >
> > Please have a look and provide your feedback on the proposal.
> > Best regards.
> >
> > --
> > Ju@N
> >
>


-- 
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jra...@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556

[image: support]  [image: twitter]
 [image: linkedin]
 [image: facebook]
 [image: google plus]
 [image: youtube]

Re: [PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Dave Barnes]

Juan,
Nice work - you've obviously given this plenty of thought. I'm not
qualified to comment on the technical aspects of your proposal, but as a
proofreader I noticed that there are a couple of occurrences of
"invokation" that should be spelled "invocation".
Dave



On Mon, Jun 25, 2018 at 2:52 AM, Ju@N  wrote:

> Hello all,
>
> The current approach used to authorize methods during OQL execution seems
> to be way too restrictive, I've drafted a proposal to change the current
> behavior and allow further customization:
> https://cwiki.apache.org/confluence/display/GEODE/
> Customizable+Security+When+Invoking+Methods+in+OQL
>
>
> Please have a look and provide your feedback on the proposal.
> Best regards.
>
> --
> Ju@N
>

[PROPOSAL]: Finer Grained Security When Invoking Methods in OQL

[Ju@N]

Hello all,

The current approach used to authorize methods during OQL execution seems
to be way too restrictive, I've drafted a proposal to change the current
behavior and allow further customization:
https://cwiki.apache.org/confluence/display/GEODE/Customizable+Security+When+Invoking+Methods+in+OQL


Please have a look and provide your feedback on the proposal.
Best regards.

-- 
Ju@N

[GitHub] geode pull request #667: GEODE-3324 Document finer-grained security permissi...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/667


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #667: GEODE-3324 Document finer-grained security permissi...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/667

GEODE-3324 Document finer-grained security permissions

@jinmeiliao @PurelyApplied @jaredjstewart @joeymcallister @davebarnes97  
Please review.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-3324

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/667.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #667


commit a15607152384e43ad16b495850596ee389cf1903
Author: Karen Miller 
Date:   2017-07-28T22:59:55Z

GEODE-3324 Document finer-grained security permissions




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied closed the pull request at:

https://github.com/apache/geode/pull/596


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/596
  
Merged as 451d12e


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/596
  
Excepting one flaky test, precheckin is green through `14298a`.  Precheckin 
is currently very unhappy, though, and starting new test runs is not going well.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/596
  
+1 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123832520
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
 ---
@@ -109,12 +107,10 @@ public Result listClient() {
   }
 
   String memberSeparator = ";  ";
-  Iterator>> it = 
clientServerMap.entrySet().iterator();
 
-  while (it.hasNext()) {
-Map.Entry> pairs = (Map.Entry>) it.next();
-String client = (String) pairs.getKey();
-List servers = (List) pairs.getValue();
+  for (Entry> pairs : clientServerMap.entrySet()) 
{
+String client = pairs.getKey();
+List servers = pairs.getValue();
 StringBuilder serverListForClient = new StringBuilder();
--- End diff --

Added in commit `b4bb08b`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123832527
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
 ---
@@ -130,31 +125,8 @@ public Result executeFunction(
 return result;
   }
 
-  if (onRegion != null && onMember != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onMember != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onMember != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onMember != null && onGroups != null) 
{
+  if (isMoreThanOneIsTrue(onRegion != null, onMember != null, onGroups 
!= null)) {
--- End diff --

Good call.  Added in commit `b4bb08b`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123830383
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBean.java
 ---
@@ -148,7 +148,12 @@ public long getInitialImageTime() {
 
   @Override
   public int getInitialImagesInProgres() {
--- End diff --

This is our internal implementation of 
`GEODE/geode-core/src/main/java/org/apache/geode/management/MemberMXBean.java`. 
 I was hesitant to remove the typo'd version from the public-facing interface 
without at least one version with it `@Deprecated`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123829882
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/management/internal/security/DiskStoreMXBeanSecurityJUnitTest.java
 ---
@@ -57,7 +56,48 @@ public void setUp() throws Exception {
   }
 
   @Test
-  @ConnectionConfiguration(user = "data-admin", password = "1234567")
+  @ConnectionConfiguration(user = "clusterRead", password = "clusterRead")
+  public void testClusterReadAccess() throws Exception {
+assertThatThrownBy(() -> 
bean.flush()).hasMessageContaining(TestCommand.diskManage.toString());
--- End diff --

Thank you regex.  Done and done in commit `97de2f3`.
For what it's worth / future reference, `s/\(\) -> 
(\w+)\.(\w+)\(\)\)/$1::$2\)` would make 3,232 test replacements, but hits no 
production files, so that's nice.  Maybe something to add to spotless down the 
line.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123822645
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
 ---
@@ -130,31 +125,8 @@ public Result executeFunction(
 return result;
   }
 
-  if (onRegion != null && onMember != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onMember != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onMember != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onGroups != null) {
-ErrorResultData errorResultData =
-
ResultBuilder.createErrorResultData().setErrorCode(ResultBuilder.ERRORCODE_DEFAULT)
-.addLine(CliStrings.EXECUTE_FUNCTION__MSG__OPTIONS);
-result = ResultBuilder.buildResult(errorResultData);
-return result;
-  } else if (onRegion != null && onMember != null && onGroups != null) 
{
+  if (isMoreThanOneIsTrue(onRegion != null, onMember != null, onGroups 
!= null)) {
--- End diff --

I like the readability introduced by this `isMoreThanOneIsTrue` method.  It 
might make sense to take the abstraction one step further: 
```
if (isMoreThanOneNonNull(onRegion, onMember, onGroup) {
```

```
  private boolean isMoreThanOneNonNull(Object... values) {
return Stream.of(values).filter(Objects::nonNull).count() > 1;
  }
```




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123820699
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
 ---
@@ -109,12 +107,10 @@ public Result listClient() {
   }
 
   String memberSeparator = ";  ";
-  Iterator>> it = 
clientServerMap.entrySet().iterator();
 
-  while (it.hasNext()) {
-Map.Entry> pairs = (Map.Entry>) it.next();
-String client = (String) pairs.getKey();
-List servers = (List) pairs.getValue();
+  for (Entry> pairs : clientServerMap.entrySet()) 
{
+String client = pairs.getKey();
+List servers = pairs.getValue();
 StringBuilder serverListForClient = new StringBuilder();
--- End diff --

Since we're already cleaning up this section of the code, it might be worth 
considering replacing 114-123 with a one liner: 

```
String serverListForClient = 
servers.stream().collect(Collectors.joining(memberSeparator));
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123819260
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBean.java
 ---
@@ -148,7 +148,12 @@ public long getInitialImageTime() {
 
   @Override
   public int getInitialImagesInProgres() {
--- End diff --

We ended up with two copies of this method, one with the correct spelling 
and one with the incorrect spelling.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123818520
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/management/internal/security/DiskStoreMXBeanSecurityJUnitTest.java
 ---
@@ -57,7 +56,48 @@ public void setUp() throws Exception {
   }
 
   @Test
-  @ConnectionConfiguration(user = "data-admin", password = "1234567")
+  @ConnectionConfiguration(user = "clusterRead", password = "clusterRead")
+  public void testClusterReadAccess() throws Exception {
+assertThatThrownBy(() -> 
bean.flush()).hasMessageContaining(TestCommand.diskManage.toString());
--- End diff --

A bunch of tests in this change set can be simplified by using method 
references in place of lambda expressions (when the lambdas take no parameters 
and invoke a no-arg method on the target):
```

assertThatThrownBy(bean::flush).hasMessageContaining(TestCommand.diskManage.toString());
```
in place of 
```
assertThatThrownBy(() -> 
bean.flush()).hasMessageContaining(TestCommand.diskManage.toString());
```



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123817037
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/CacheServerMXBean.java ---
@@ -60,48 +61,48 @@
   /**
* Returns the port on which this CacheServer listens for clients.
*/
-  public int getPort();
+  int getPort();
--- End diff --

I think this should be ok actually, since CacheServerMXBean is an interface 
and not a class.  (So all methods will be public by default.)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[jaredjstewart]

Github user jaredjstewart commented on a diff in the pull request:

https://github.com/apache/geode/pull/596#discussion_r123815346
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/CacheServerMXBean.java ---
@@ -60,48 +61,48 @@
   /**
* Returns the port on which this CacheServer listens for clients.
*/
-  public int getPort();
+  int getPort();
--- End diff --

Why are we removing public from all of these methods?  I think 
CacheServerMXBean is a public facing API and intends to expose these methods.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/596
  
Precheckin running.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #596: GEODE-2920 - GEODE-2925: Finer Grained Security

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

https://github.com/apache/geode/pull/596

GEODE-2920 - GEODE-2925: Finer Grained Security

Due to the size of this commit and for your convenience of review, I have 
not yet squashed my commits.  Do note that I have not individually tested each 
individual commit for stability and each internal commit is meant only for ease 
of review.

The commit message to be included in the final, squashed version of this PR 
is present in the `8fe19ca`... commit, and reproduced below.

TODO: 
[ ] Is your initial contribution a single, squashed commit?

-

This commit represents the actual Finer Grained Security changes.
GEODE-2920 - GEODE-2925: Migration of security from DATA:MANAGE
* DATA:MANAGE -> CLUSTER:MANAGE
*
* configure pdx
* import cluster-configuration
* LockServiceMXBean.becomeLockGrantor
*
* DATA:MANAGE -> CLUSTER:MANAGE:DISK
*
* compact disk-store
* create disk-store
* destroy disk-store
* revoke missing-disk-store
* DiskStoreMXBean.forceRoll
* DiskStoreMXBean.forceCompaction
* DiskStoreMXBean.flush
* DiskStoreMXBean.setDiskUsageWarningPercentage
* DiskStoreMXBean.setDiskUsageCriticalPercentage
* DistributedSystemMXBean.revokeMissingDiskStores
* MemberMXBean.compactAllDistStores
*
* DATA:MANAGE -> CLUSTER:MANAGE:GATEWAY
*
* create gateway-receiver
* create gateway-sender
* destroy gateway-sender
* load-balance gateway-sender
* pause gateway-sender
* resume gateway-sender
* start gateway-receiver
* start gateway-sender
* stop gateway-receiver
* stop gateway-sender
* GatewayReceiverMXBean.start
* GatewayReceiverMXBean.stop
* GatewaySenderMXBean.start
* GatewaySenderMXBean.stop
* GatewaySenderMXBean.pause
* GatewaySenderMXBean.resume
* GatewaySenderMXBean.rebalance
*
* DATA:MANAGE -> CLUSTER:MANAGE:JAR
*
* create async-event-queue (Requires CLUSTER:WRITE:DISK if persistent)
* destroy function
* undeploy
*
* DATA:MANAGE -> CLUSTER:MANAGE:QUERY
*
* clear defined indexes
* close durable-client
* close durable-cq
* create defined indexes
* stop continuous-query
* CacheServerMXBean.closeAllContinuousQuery
* CacheServerMXBean.closeContinuousQuery
* DistributedSystemMXBean.setQueryResultSetLimit
* DistributedSystemMXBean.setQueryCollectionsDepth
*
* DATA:READ -> CLUSTER:READ
*
* list region
*
* DATA:MANAGE -> [None]
*
* pdx rename
*
* DATA:READ -> DATA:READ and CLUSTER:WRITE:DISK
*
* backup disk-store
* DistributedSystemMXBean.backupAllMembers
*
* DATA:MANAGE:RegionName -> CLUSTER:MANAGE:QUERY
*
* create index
* create lucene index (also requires CLUSTER:WRITE:DISK)
* define index
* destroy lucene index
*
* DATA:MANAGE, DATA:WRITE, CLUSTER:MANAGE, and CLUSTER:WRITE -> 
CLUSTER:MANAGE:JAR
*
* deploy
*
* DATA:MANAGE or DATA:MANAGE:RegionName -> CLUSTER:MANAGE:QUERY
*
* destroy index
*
* CLUSTER:READ -> CLUSTER:READ:QUERY
*
* describe lucene index
* list index
* list lucene indexes
*
* DATA:WRITE -> DATA:READ:Region
*
* search lucene index
*
* DATA:MANAGE -> DATA:MANAGE and CLUSTER:WRITE:DISK if persistent
*
* create region

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PurelyApplied/geode geode-2924

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/596.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #596


commit 8b14112094fd49bfc7638cc952f8d322d5bd50e7
Author: Patrick Rhomberg 
Date:   2017-06-21T17:51:32Z

For ease of viewing, this commit covers all necessary imports.

commit 8fe19ca6ff3e51aed601537afb8e23c3e85569a1
Author: Patrick Rhomberg 
Date:   2017-06-21T18:59:13Z

    This commit represents the actual Finer Grained Security changes.

GEODE-2920 - GEODE-2925: Migration of security from DATA:MANAGE
* DATA:MANAGE -> CLUSTER:MANAGE
*
* configure pdx
* import cluster-configuration
* LockServiceMXBean.becomeLockGrantor
*
* DATA:MANAGE -> CLUSTER:MANAGE:DISK
*
* compact disk-store
* create disk-store
* destroy disk-store
* revoke missing-disk-store
* DiskStoreMXBean.forceRoll
* DiskStoreMXBean.forceCompaction
* DiskStoreMXBean.flush
* DiskStoreMXBean.setDiskUsageWarningPercentage
* DiskStoreMXBean.setDiskUsageCriticalPercentage
* DistributedSystemMXBean.revokeMissingDiskStores
* MemberMXBean.compactAllDistStores
*
* DATA:MANAGE -> CLUSTER:MANAGE:GATEW

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

> On June 12, 2017, 5 p.m., Kirk Lund wrote:
> > I recommend pulling out the changes to SecurityService creation. The 
> > changes I have on the feature branch prevent a Locator from allowing 
> > unsecured joins before the Locator creates its Cache.

Sounds good. I will rebase my change on top of yours then.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review177641
---


On June 12, 2017, 2:44 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 12, 2017, 2:44 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 9b23f6c1a8ed3449d8a49029d6364f1e989e367c 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  2988ffd43ae1985c527a1082d91b2782b03eced0 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  22edb6f06c7791929cc9a033ca1a1bfed5751a47 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  deea55ff085762a2dd91ebdc57475e42724dee04 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  b682d93fd5c4b5340e2c30be72c5572e031e26ed 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  c52ccbc1cc5a293d70b177e38f03dc17c7db 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  01d99951bc70547fb311f2edbfec8dde1be799f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  2d6af1a22644d427ec2d17863cef27a8d8961491 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  f895b964794f99127f1f0c9564f3f85213e0af22 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de565a8301168f13e1917ea739a8879162c 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/CallbackInstantiator.java
>  3ff632d3857189513243959ee96da89da66d5a27 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/CustomSecurityService.java
>  c4946e768ee70db00030defa76da7d21d33c6e0c 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/DisabledSecurityService.java
>  d328946632c1d0defc86aa0527208a841b9b45ba 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/EnabledSecurityService.java
>  f971deef0807534a014236d37ba48bafa307c56b 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/LegacySecurityService.java
>  ef92bb7415c05ae09511e38d8a850f386de23033 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  be81582b74a4359f74d483ca64c6e42f6b081738 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceFactory.java
>  02f34f15617f7bf4ad9ee7fa51f32be4db3c198a 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceType.java
>  8ae76d22b628b3175db45116b80dfcfbe34aba1d 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/ConfigInitializer.java
>  60f014b9c33732a4ea134a654e666a9439b210bb 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/CustomAuthRealm.java
>  51449fdd5570494f3cf91325985a5eb9fc9f6d57 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/RealmInitializer.java
>  978c4dd0ab92afde53972f7feb9d8f018d0bf662 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda8437e06de818ead40731818f937c3aef5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  7ec7699821c9f5572aebeb0936ad3617e802c07e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  365c6ae01994cd0d5c06e523c42b6bec19c14c5d 
>   
> geode-c

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review177641
---



I recommend pulling out the changes to SecurityService creation. The changes I 
have on the feature branch prevent a Locator from allowing unsecured joins 
before the Locator creates its Cache.

- Kirk Lund


On June 12, 2017, 2:44 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 12, 2017, 2:44 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 9b23f6c1a8ed3449d8a49029d6364f1e989e367c 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  2988ffd43ae1985c527a1082d91b2782b03eced0 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  22edb6f06c7791929cc9a033ca1a1bfed5751a47 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  deea55ff085762a2dd91ebdc57475e42724dee04 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  b682d93fd5c4b5340e2c30be72c5572e031e26ed 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  c52ccbc1cc5a293d70b177e38f03dc17c7db 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  01d99951bc70547fb311f2edbfec8dde1be799f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  2d6af1a22644d427ec2d17863cef27a8d8961491 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  f895b964794f99127f1f0c9564f3f85213e0af22 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de565a8301168f13e1917ea739a8879162c 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/CallbackInstantiator.java
>  3ff632d3857189513243959ee96da89da66d5a27 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/CustomSecurityService.java
>  c4946e768ee70db00030defa76da7d21d33c6e0c 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/DisabledSecurityService.java
>  d328946632c1d0defc86aa0527208a841b9b45ba 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/EnabledSecurityService.java
>  f971deef0807534a014236d37ba48bafa307c56b 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/LegacySecurityService.java
>  ef92bb7415c05ae09511e38d8a850f386de23033 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  be81582b74a4359f74d483ca64c6e42f6b081738 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceFactory.java
>  02f34f15617f7bf4ad9ee7fa51f32be4db3c198a 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceType.java
>  8ae76d22b628b3175db45116b80dfcfbe34aba1d 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/ConfigInitializer.java
>  60f014b9c33732a4ea134a654e666a9439b210bb 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/CustomAuthRealm.java
>  51449fdd5570494f3cf91325985a5eb9fc9f6d57 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/shiro/RealmInitializer.java
>  978c4dd0ab92afde53972f7feb9d8f018d0bf662 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda8437e06de818ead40731818f937c3aef5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  7ec7699821c9f5572aebeb0936ad3617e802c07e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  365c6ae01994cd0d5c06e523c42b6bec19c14c5d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  345d688c10c0477904ceb4c5a52302b7bd3eaec9 

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 12, 2017, 2:44 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

While rebasing this changeset to develop to pick up Kirk's security work, I got 
a bit carried away in refactoring. Below are the main points of this changeset:

1) move the creation of the security service back to GemfireCacheImpl, so that 
the security manager property recevied in the cluster configuration will take 
effect. (mainly reverted the changes under distributed.internal.membership 
package)
2) consolidate the implementation of SecurityService into two: 
IntegratedSecurityService and LegacySecurityService to avoid code duplication.
3) added default implemenation of SecurityService (debateble)
4) reworked SecurityServicefactory and add more tests.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
9b23f6c1a8ed3449d8a49029d6364f1e989e367c 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
 2988ffd43ae1985c527a1082d91b2782b03eced0 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
 22edb6f06c7791929cc9a033ca1a1bfed5751a47 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
 deea55ff085762a2dd91ebdc57475e42724dee04 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
 b682d93fd5c4b5340e2c30be72c5572e031e26ed 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
 c52ccbc1cc5a293d70b177e38f03dc17c7db 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
 01d99951bc70547fb311f2edbfec8dde1be799f7 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
 2d6af1a22644d427ec2d17863cef27a8d8961491 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
 f895b964794f99127f1f0c9564f3f85213e0af22 
  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de565a8301168f13e1917ea739a8879162c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
40df0c7dcac8827a381c268c1f90e6acfb97a7f1 
  
geode-core/src/main/java/org/apache/geode/internal/security/CallbackInstantiator.java
 3ff632d3857189513243959ee96da89da66d5a27 
  
geode-core/src/main/java/org/apache/geode/internal/security/CustomSecurityService.java
 c4946e768ee70db00030defa76da7d21d33c6e0c 
  
geode-core/src/main/java/org/apache/geode/internal/security/DisabledSecurityService.java
 d328946632c1d0defc86aa0527208a841b9b45ba 
  
geode-core/src/main/java/org/apache/geode/internal/security/EnabledSecurityService.java
 f971deef0807534a014236d37ba48bafa307c56b 
  
geode-core/src/main/java/org/apache/geode/internal/security/LegacySecurityService.java
 ef92bb7415c05ae09511e38d8a850f386de23033 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 be81582b74a4359f74d483ca64c6e42f6b081738 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceFactory.java
 02f34f15617f7bf4ad9ee7fa51f32be4db3c198a 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityServiceType.java
 8ae76d22b628b3175db45116b80dfcfbe34aba1d 
  
geode-core/src/main/java/org/apache/geode/internal/security/shiro/ConfigInitializer.java
 60f014b9c33732a4ea134a654e666a9439b210bb 
  
geode-core/src/main/java/org/apache/geode/internal/security/shiro/CustomAuthRealm.java
 51449fdd5570494f3cf91325985a5eb9fc9f6d57 
  
geode-core/src/main/java/org/apache/geode/internal/security/shiro/RealmInitializer.java
 978c4dd0ab92afde53972f7feb9d8f018d0bf662 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda8437e06de818ead40731818f937c3aef5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 7ec7699821c9f5572aebeb0936ad3617e802c07e 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 365c6ae01994cd0d5c06e523c42b6bec19c14c5d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 345d688c10c0477904ceb4c5a52302b7bd3eaec9 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review177383
---


Ship it!




Ship it after GEODE-2632 is merged to develop.

- Kirk Lund


On June 5, 2017, 6:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 5, 2017, 6:32 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de565a8301168f13e1917ea739a8879162c 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cfe8c181b0a0874869a66643c00300f98 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391212095413c0d577cfc65de7247080b5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda8437e06de818ead40731818f937c3aef5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e52611994ddc16a58414146ebaad75c65 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb470c79f383626b8e15e3bd8650377dd 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8c4b11f013d0800baf2a1d9f18cb7f1d 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b015ae0ffb5a648fe026bb01bc6128df8 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/7/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 5, 2017, 6:32 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

added a new interface method according review.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de565a8301168f13e1917ea739a8879162c 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cfe8c181b0a0874869a66643c00300f98 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391212095413c0d577cfc65de7247080b5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda8437e06de818ead40731818f937c3aef5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e52611994ddc16a58414146ebaad75c65 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb470c79f383626b8e15e3bd8650377dd 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8c4b11f013d0800baf2a1d9f18cb7f1d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b015ae0ffb5a648fe026bb01bc6128df8 


Diff: https://reviews.apache.org/r/59692/diff/7/

Changes: https://reviews.apache.org/r/59692/diff/6-7/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Patrick Rhomberg]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176859
---




geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
Line 71 (original)
<https://reviews.apache.org/r/59692/#comment250336>

We could use an `authorize(Resource r, Operation o, Target t)` that infers 
`key = "*"`


- Patrick Rhomberg


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > <https://reviews.apache.org/r/59692/diff/4/?file=1738269#file1738269line33>
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.
> 
> Jinmei Liao wrote:
> I tried to do this, but it's more involved than just adding the 
> repeatable annoation here. The user of these annotations will need to be 
> updated to handle multiple values. Possibly for future enhancement.
> 
> Patrick Rhomberg wrote:
> Here's a diff on my branch that I think does what we want.
> 
> 
> https://github.com/PurelyApplied/geode/commit/e82688ffb08e4b4542d2f440cb62d46d2b7bcf3c
> 
> Am I missing a use case where 
> `method.getAnnotation(ResourceOperation.class)` is going to be used by some 
> user's custom implementations?  Because otherwise we only need to change the 
> annotation processing in `CommandProcessor::executeCommand`, as far as I can 
> tell.

this works for annotations we added on commands. This annotation is also used 
on MXBeans, e.g. MemberMXBean, the place where it's parsing that info is in 
MBeanServerWrapper.getOperationContext(), that's where it's give us hickups.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176684
---


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Patrick Rhomberg]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > <https://reviews.apache.org/r/59692/diff/4/?file=1738269#file1738269line33>
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.
> 
> Jinmei Liao wrote:
> I tried to do this, but it's more involved than just adding the 
> repeatable annoation here. The user of these annotations will need to be 
> updated to handle multiple values. Possibly for future enhancement.

Here's a diff on my branch that I think does what we want.

https://github.com/PurelyApplied/geode/commit/e82688ffb08e4b4542d2f440cb62d46d2b7bcf3c

Am I missing a use case where `method.getAnnotation(ResourceOperation.class)` 
is going to be used by some user's custom implementations?  Because otherwise 
we only need to change the annotation processing in 
`CommandProcessor::executeCommand`, as far as I can tell.


- Patrick


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176684
---


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 2, 2017, 4:08 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de56 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cf 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda84 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e5 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da46441 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271e 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d19 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b0 


Diff: https://reviews.apache.org/r/59692/diff/6/

Changes: https://reviews.apache.org/r/59692/diff/5-6/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > <https://reviews.apache.org/r/59692/diff/4/?file=1738269#file1738269line33>
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.

I tried to do this, but it's more involved than just adding the repeatable 
annoation here. The user of these annotations will need to be updated to handle 
multiple values. Possibly for future enhancement.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176684
---


On June 2, 2017, 2:31 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 2:31 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/5/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 2, 2017, 2:31 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

review changes


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de56 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cf 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda84 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e5 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da46441 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271e 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d19 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b0 


Diff: https://reviews.apache.org/r/59692/diff/5/

Changes: https://reviews.apache.org/r/59692/diff/4-5/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Patrick Rhomberg]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176684
---




geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
Line 29 (original), 30 (patched)
<https://reviews.apache.org/r/59692/#comment250101>

Is it possible to make this `@Repeatable`?  There are some operations that 
require multiple security permissions, and it would be nice to be able to just 
annotate those functions twice.

For instance, `DistributedSystemMXBean.backupAllMembers` should have 
`DATA:READ` and `CLUSTER:WRITE:DISK`.


- Patrick Rhomberg


On June 1, 2017, 5:21 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 1, 2017, 5:21 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391212095413c0d577cfc65de7247080b5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/4/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Patrick Rhomberg]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176672
---




geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
Lines 37-40 (patched)
<https://reviews.apache.org/r/59692/#comment250088>

This is internally inconsistent.  I'd either change the import all the way 
to 
`import org.apache.geode.security.ResourcePermission.Target;`
or update the above `Resource` and `Operation` references to extend their 
package, i.e. to include `ResourcePermission.Resource`.


- Patrick Rhomberg


On June 1, 2017, 5:21 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 1, 2017, 5:21 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> -------
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391212095413c0d577cfc65de7247080b5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/4/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Ken Howe]

> On June 1, 2017, 5:09 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
> > Lines 228 (patched)
> > <https://reviews.apache.org/r/59692/diff/3/?file=1737978#file1737978line228>
> >
> > I think it might be nice to have a variant of `authorize()` that takes 
> > a Resource/Operation/Target rather than their String representations:
> > 
> > ```
> >   public void authorize(Resource resource, Operation operation){} 
> >   public void authorize(Resource resource, Operation operation, Target 
> > target){} 
> > 
> > ```
> > 
> > Then these methods would look like
> > ```
> > public void authorizeDiskManage() {
> > authorize(Resource.CLUSTER, Operation.MANAGE, 
> > ResourcePermission.Target.DISK);
> >   }
> > ```

Target can be a region name as well as the as a Target enum. Consequently, the 
ResourcePermission constructors that the authorize methods call currently all 
expect target as a string.


- Ken


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176626
---


On June 1, 2017, 5:21 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 1, 2017, 5:21 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391212095413c0d577cfc65de7247080b5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/4/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 1, 2017, 5:21 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391212095413c0d577cfc65de7247080b5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 


Diff: https://reviews.apache.org/r/59692/diff/4/

Changes: https://reviews.apache.org/r/59692/diff/3-4/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176626
---




geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
Lines 197 (patched)
<https://reviews.apache.org/r/59692/#comment249990>

I might have expected a `NotAuthorizedException` if the current user is 
`null`.  What makes us want to default to authorized in that case?



geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
Lines 228 (patched)
<https://reviews.apache.org/r/59692/#comment249989>

I think it might be nice to have a variant of `authorize()` that takes a 
Resource/Operation/Target rather than their String representations:

```
  public void authorize(Resource resource, Operation operation){} 
  public void authorize(Resource resource, Operation operation, Target 
target){} 

```

Then these methods would look like
```
public void authorizeDiskManage() {
authorize(Resource.CLUSTER, Operation.MANAGE, 
ResourcePermission.Target.DISK);
  }
```



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
Lines 410 (patched)
<https://reviews.apache.org/r/59692/#comment249991>

If you add the same style of static import used by `Resource` and 
`Operation` here for `Target` as well I think it will read a little nicer.


- Jared Stewart


On June 1, 2017, 4:41 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 1, 2017, 4:41 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391212095413c0d577cfc65de7247080b5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 1, 2017, 4:41 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Changes
---

add more methods in security service


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391212095413c0d577cfc65de7247080b5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 


Diff: https://reviews.apache.org/r/59692/diff/3/

Changes: https://reviews.apache.org/r/59692/diff/2-3/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

(Updated June 1, 2017, 3:50 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 


Diff: https://reviews.apache.org/r/59692/diff/2/

Changes: https://reviews.apache.org/r/59692/diff/1-2/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/#review176533
---




geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java
Line 77 (original), 95 (patched)
<https://reviews.apache.org/r/59692/#comment249906>

I think it would be better to use Region.SEPARATOR instead of "/".


- Ken Howe


On May 31, 2017, 8:55 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated May 31, 2017, 8:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59692/
---

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 


Diff: https://reviews.apache.org/r/59692/diff/1/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

[jira] [Created] (GEODE-2987) document finer grained security migration

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2987:
---

 Summary: document finer grained security migration
 Key: GEODE-2987
 URL: https://issues.apache.org/jira/browse/GEODE-2987
 Project: Geode
  Issue Type: Sub-task
  Components: docs
Reporter: Swapnil Bawaskar


We need to document how a user will migrate to the new finer grained security 
model from that in 1.2 release.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2919) Provide finer grained security

[Joey McAllister (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joey McAllister updated GEODE-2919:
---
Component/s: docs

> Provide finer grained security
> --
>
> Key: GEODE-2919
> URL: https://issues.apache.org/jira/browse/GEODE-2919
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, security
>Reporter: Swapnil Bawaskar
>
> 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.
> Please see this discussion on the mailing list: 
> https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2919) Provide finer grained security

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-2919:
---

 Summary: Provide finer grained security
 Key: GEODE-2919
 URL: https://issues.apache.org/jira/browse/GEODE-2919
 Project: Geode
  Issue Type: Improvement
  Components: security
Reporter: Swapnil Bawaskar


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.

Please see this discussion on the mailing list: 
https://lists.apache.org/thread.html/f96842276e93d8a6c3080ad3982c72431d62d1e7c717ebbc50941968@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Finer grained security

[Swapnil Bawaskar]

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.
>
> 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
> > 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 
> 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  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 
> > > > 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.
> > >

Re: Finer grained security

[John Blum]

+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
> 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  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>
> >
> > 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  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 
> > > 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
> > > 

Re: Finer grained security

[Jacob Barrett]

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  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>
>
> On Thu, Apr 27, 2017 at 2:11 PM, pulkit chandra 
> 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  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 
> > 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
> gr

Re: Finer grained security

[Michael Stolz]

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 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  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 
> 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 
> > > > 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  >
> > > > 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
> > 

Re: Finer grained security

[pulkit chandra]

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  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 
> 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  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 
> > > 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 
> > > 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
> > >
> >
>

Re: Finer grained security

[Dan Smith]

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 
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  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 
> > 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 
> > 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
> >
>

Re: Finer grained security

[Diane Rose Hardman]

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  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 
> 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 
> 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 
> > > 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
>

Re: Finer grained security

[Jinmei Liao]

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 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 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 
> > 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

Re: Finer grained security

[Jacob Barrett]

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 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 
> 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?
>
>

Re: Finer grained security

[Jared Stewart]

+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  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?

Finer grained security

[Swapnil Bawaskar]

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?