[JBoss JIRA] (ISPN-8059) HotRod keySet operation requires ADMIN permissions
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-8059?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-8059:
--------------------------------
Description:
Steps to reproduce:
1) uncomment testKeySet in HotRodOperationsAuthzIT#testSupervisor
(note that the supervisor has BULK_READ permission defined in configuration)
2) run the test in the server test suite
This bug seems to be resolved in current master branch (9.1.0-SNAPSHOT - commit 5c5ff99) as I wasn't able to reproduce it there.
Stacktrace:
{code}
testSupervisor(org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT) Time elapsed: 0.216 sec <<< ERROR!
org.infinispan.client.hotrod.exceptions.HotRodClientException: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [SimpleUserPrincipal [name=supervisor], InetAddressPrincipal [address=127.0.0.1/127.0.0.1], supervisor@ApplicationRealm, supervisor@ApplicationRealm, supervisor]' lacks 'ADMIN' permission
at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:39)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:20)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.keySet(RemoteCacheImpl.java:529)
at org.infinispan.server.test.client.hotrod.security.HotRodAuthzOperationTests.testKeySet(HotRodAuthzOperationTests.java:113)
at org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT.testSupervisor(HotRodOperationsAuthzIT.java:111)
{code}
was:
Steps to reproduce:
1) uncomment testKeySet in HotRodOperationsAuthzIT#testSupervisor
(note that the supervisor has BULK_READ permission defined in configuration)
2) run the test in the server test suite
This bug seems to be resolved in current master branch (9.1.0-SNAPSHOT) as I wasn't able to reproduce it there.
Stacktrace:
{code}
testSupervisor(org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT) Time elapsed: 0.216 sec <<< ERROR!
org.infinispan.client.hotrod.exceptions.HotRodClientException: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [SimpleUserPrincipal [name=supervisor], InetAddressPrincipal [address=127.0.0.1/127.0.0.1], supervisor@ApplicationRealm, supervisor@ApplicationRealm, supervisor]' lacks 'ADMIN' permission
at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:39)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:20)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.keySet(RemoteCacheImpl.java:529)
at org.infinispan.server.test.client.hotrod.security.HotRodAuthzOperationTests.testKeySet(HotRodAuthzOperationTests.java:113)
at org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT.testSupervisor(HotRodOperationsAuthzIT.java:111)
{code}
> HotRod keySet operation requires ADMIN permissions
> --------------------------------------------------
>
> Key: ISPN-8059
> URL: https://issues.jboss.org/browse/ISPN-8059
> Project: Infinispan
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.3.Final
> Reporter: Martin Gencur
>
> Steps to reproduce:
> 1) uncomment testKeySet in HotRodOperationsAuthzIT#testSupervisor
> (note that the supervisor has BULK_READ permission defined in configuration)
> 2) run the test in the server test suite
> This bug seems to be resolved in current master branch (9.1.0-SNAPSHOT - commit 5c5ff99) as I wasn't able to reproduce it there.
> Stacktrace:
> {code}
> testSupervisor(org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT) Time elapsed: 0.216 sec <<< ERROR!
> org.infinispan.client.hotrod.exceptions.HotRodClientException: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [SimpleUserPrincipal [name=supervisor], InetAddressPrincipal [address=127.0.0.1/127.0.0.1], supervisor@ApplicationRealm, supervisor@ApplicationRealm, supervisor]' lacks 'ADMIN' permission
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
> at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:39)
> at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:20)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.keySet(RemoteCacheImpl.java:529)
> at org.infinispan.server.test.client.hotrod.security.HotRodAuthzOperationTests.testKeySet(HotRodAuthzOperationTests.java:113)
> at org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT.testSupervisor(HotRodOperationsAuthzIT.java:111)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-8059) HotRod keySet operation requires ADMIN permissions
by Martin Gencur (JIRA)
Martin Gencur created ISPN-8059:
-----------------------------------
Summary: HotRod keySet operation requires ADMIN permissions
Key: ISPN-8059
URL: https://issues.jboss.org/browse/ISPN-8059
Project: Infinispan
Issue Type: Bug
Components: Security
Affects Versions: 9.0.3.Final
Reporter: Martin Gencur
Steps to reproduce:
1) uncomment testKeySet in HotRodOperationsAuthzIT#testSupervisor
(note that the supervisor has BULK_READ permission defined in configuration)
2) run the test in the server test suite
This bug seems to be resolved in current master branch (9.1.0-SNAPSHOT) as I wasn't able to reproduce it there.
Stacktrace:
{code}
testSupervisor(org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT) Time elapsed: 0.216 sec <<< ERROR!
org.infinispan.client.hotrod.exceptions.HotRodClientException: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'Subject with principal(s): [SimpleUserPrincipal [name=supervisor], InetAddressPrincipal [address=127.0.0.1/127.0.0.1], supervisor@ApplicationRealm, supervisor@ApplicationRealm, supervisor]' lacks 'ADMIN' permission
at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:363)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:152)
at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:138)
at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:39)
at org.infinispan.client.hotrod.impl.operations.BulkGetKeysOperation.executeOperation(BulkGetKeysOperation.java:20)
at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
at org.infinispan.client.hotrod.impl.RemoteCacheImpl.keySet(RemoteCacheImpl.java:529)
at org.infinispan.server.test.client.hotrod.security.HotRodAuthzOperationTests.testKeySet(HotRodAuthzOperationTests.java:113)
at org.infinispan.server.test.client.hotrod.security.HotRodOperationsAuthzIT.testSupervisor(HotRodOperationsAuthzIT.java:111)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7998) Multi-key write commands assume all segments have CH.getNumOwners() owners
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7998?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7998:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Multi-key write commands assume all segments have CH.getNumOwners() owners
> --------------------------------------------------------------------------
>
> Key: ISPN-7998
> URL: https://issues.jboss.org/browse/ISPN-7998
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Beta1, 9.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.1.0.Final
>
>
> When handling multi-key write commands, both {{TriangleDistributionInterceptor}} and {{NonTxDistributionInterceptor}} assume that there are no backup owners when {{consistentHash.getNumOwners() == 1}}. But during rebalance some segments can have more than {{getNumOwners()}} owners, as the write CH is a union of the current and future CHs, while {{getNumOwners()}} always returns the value in the cache configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7973) Investigate Service Brokers
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-7973:
-------------------------------------------
Things to clarify and other issues:
* No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it).
* Shall we create separate separate service or one service with multiple plans?
> Investigate Service Brokers
> ---------------------------
>
> Key: ISPN-7973
> URL: https://issues.jboss.org/browse/ISPN-7973
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7973) Investigate Service Brokers
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:08 AM:
--------------------------------------------------------------------
Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]:
* Marko implemented En Masse.
* The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances.
* The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate.
* The Broker can instantiate the service synchronously or asynchronously.
* The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around.
* An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services)
* The Boker Pod can provide its own UI (it's just a running Pod).
Things to clarify and other issues:
* No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it).
* Shall we create separate separate service or one service with multiple plans?
was (Author: sebastian.laskawiec):
Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]:
* Marko implemented En Masse.
* The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances.
* The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate.
* The Broker can instantiate the service synchronously or asynchronously.
* The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around.
* An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services)
* The Boker Pod can provide its own UI (it's just a running Pod).
*
Ideas:
* We may use the Broker to instrument the deployed JDG instances
* We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster.
* During the bind operation we should provide {{hotrod-client.properties}}.
*
Things to clarify and other issues:
* No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it).
* Shall we create separate separate service or one service with multiple plans?
> Investigate Service Brokers
> ---------------------------
>
> Key: ISPN-7973
> URL: https://issues.jboss.org/browse/ISPN-7973
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7973) Investigate Service Brokers
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-7973:
-------------------------------------------
Ideas:
* We may use the Broker to instrument the deployed JDG instances
* We may use the Broker to instantiate JDG instances outside of the cloud. During the Bind step we could provide credentials to connect to it. In addition to that we'd need to manually facilitate {{Endpoints}} objects pointing to the cluster.
* During the bind operation we should provide {{hotrod-client.properties}}.
> Investigate Service Brokers
> ---------------------------
>
> Key: ISPN-7973
> URL: https://issues.jboss.org/browse/ISPN-7973
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7973) Investigate Service Brokers
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-7973?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec edited comment on ISPN-7973 at 7/12/17 4:09 AM:
--------------------------------------------------------------------
Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]:
* Marko implemented En Masse.
* The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances.
* The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate.
* The Broker can instantiate the service synchronously or asynchronously.
* The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around.
* An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services)
* The Boker Pod can provide its own UI (it's just a running Pod).
was (Author: sebastian.laskawiec):
Based on [discussion between Marko Luksa and Emmanuel Bernard|https://bluejeans.com/s/uij6Y]:
* Marko implemented En Masse.
* The Broker controls instances it created. E.g. we might imagine having a JDG Broker which will add a cache to all living instances.
* The {{ServicePlan}} is a resource incorporated into {{ServiceClass}}. It is not separate.
* The Broker can instantiate the service synchronously or asynchronously.
* The client can specify the name of a {{Secret}} with credentials. Currently users need to preconfigure their apps (to use the secret provided by the Catalog). There are plans to make it the other way around.
* An {{Endpoints}} object contains a list of IP addresses and ports to desired Pods (or other type of services)
* The Boker Pod can provide its own UI (it's just a running Pod).
Things to clarify and other issues:
* No UI for creating/deleting/editing ServicePlans. It is also worth to mention that OpenShift Origin (with {{oc cluster up}}) comes with one default plan (use {{oc edit ServiceClass infinispan-ephemeral}} to view it).
* Shall we create separate separate service or one service with multiple plans?
> Investigate Service Brokers
> ---------------------------
>
> Key: ISPN-7973
> URL: https://issues.jboss.org/browse/ISPN-7973
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months