[JBoss JIRA] (ISPN-7207) Cache creation requires specific permissions when using security manager
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/ISPN-7207?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on ISPN-7207:
----------------------------------
IMO the aim should be to remove as many of the deployment permissions as possible from https://github.com/wildfly/wildfly/pull/9254
> Cache creation requires specific permissions when using security manager
> ------------------------------------------------------------------------
>
> Key: ISPN-7207
> URL: https://issues.jboss.org/browse/ISPN-7207
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Paul Ferraro
> Assignee: Ingo Weiss
>
> *org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase#test*
> {{./integration-tests.sh -DtestLogToFile=false -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.injection.resource.infinispan.InfinispanResourceRefTestCase -Dsecurity.manager}}
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/infinispan-resource-ref.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.infinispan-resource-ref.war:main" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1442)
> at org.infinispan.commons.util.Util.getClassLoaders(Util.java:127)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:163)
> at org.infinispan.commons.util.ReflectionUtil.getClassForName(ReflectionUtil.java:319)
> at org.infinispan.commons.util.ReflectionUtil.toClassArray(ReflectionUtil.java:313)
> at org.infinispan.factories.AbstractComponentRegistry$Component.buildInjectionMethodsList(AbstractComponentRegistry.java:810)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:213)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:193)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:171)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:163)
> at org.infinispan.factories.ComponentRegistry.<init>(ComponentRegistry.java:79)
> ... 210 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ISPN-7310) Make Console Use Digest Authentication
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7310?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7310:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Beta2
Resolution: Done
> Make Console Use Digest Authentication
> --------------------------------------
>
> Key: ISPN-7310
> URL: https://issues.jboss.org/browse/ISPN-7310
> Project: Infinispan
> Issue Type: Enhancement
> Components: Console
> Affects Versions: 9.0.0.Beta1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Beta2
>
>
> We need to make the console utilise digest authentication as it is more secure than basic authentication when not utilising HTTPs and because IE doesn't currently support the previously used user:pass@host url's previously employed by the console.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-28) Node kill pkill commands failing in some envs
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-28?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño resolved HRJS-28.
----------------------------------
Resolution: Duplicate Issue
Duplicates HRJS-25.
> Node kill pkill commands failing in some envs
> ---------------------------------------------
>
> Key: HRJS-28
> URL: https://issues.jboss.org/browse/HRJS-28
> Project: Infinispan Javascript client
> Issue Type: Enhancement
> Affects Versions: 0.3.0
> Reporter: Galder Zamarreño
>
> On certain environments (e.g. Ubuntu), tests involving killing nodes are failing with errors like this:
> {code}
> 1) Infinispan cluster client can failover when nodes crash
> Message:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
> Stacktrace:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
> at ChildProcess.exithandler (child_process.js:213:12)
> at emitTwo (events.js:87:13)
> at ChildProcess.emit (events.js:172:7)
> at maybeClose (internal/child_process.js:821:16)
> at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
> ...
> 5) Infinispan xsite cluster client can manually switch and fail over sites
> Message:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
> Stacktrace:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
> at ChildProcess.exithandler (child_process.js:213:12)
> at emitTwo (events.js:87:13)
> at ChildProcess.emit (events.js:172:7)
> at maybeClose (internal/child_process.js:821:16)
> at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
> {code}
> After doing some debugging, we discovered that the error itself contains this info:
> {code}
> {"killed":false,"code":null,"signal":"SIGKILL","cmd":"/bin/sh -c pkill -9 -f '.*java.*node4 .*'"}
> {code}
> According to the docu:
> {code}
> If the process terminated normally, code is the final exit code of the process, otherwise null. If the process terminated due to receipt of a signal, signal is the string name of the signal, otherwise null.
> {code}
> So, it would appear that {{pkill}} is killing itself?
> The easiest workaround here might be to ignore any errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-29) Security related error messages vary between Node versions
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-29?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated HRJS-29:
---------------------------------
Status: Open (was: New)
> Security related error messages vary between Node versions
> ----------------------------------------------------------
>
> Key: HRJS-29
> URL: https://issues.jboss.org/browse/HRJS-29
> Project: Infinispan Javascript client
> Issue Type: Bug
> Reporter: Galder Zamarreño
>
> Currently testsuite works fine with Node 0.10. When running for example with Node 4.x, you get errors like this:
> {code}
> 2) Infinispan TLS/SSL client can operate on data via crypto store trusted encrypted transport
> Message:
> Error: self signed certificate in certificate chain
> Stacktrace:
> Error: self signed certificate in certificate chain
> at Error (native)
> at TLSSocket.<anonymous> (_tls_wrap.js:1016:38)
> at emitNone (events.js:67:13)
> at TLSSocket.emit (events.js:166:7)
> at TLSSocket._finishInit (_tls_wrap.js:585:8)
> 3) Infinispan TLS/SSL client fails to operate if default server name (SNI) does not match default server realm
> Message:
> Expected 'Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not cert's CN: untrusted.acme"' to be 'Hostname/IP doesn't match certificate's altnames'.
> Stacktrace:
> Error: Expected 'Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not cert's CN: untrusted.acme"' to be 'Hostname/IP doesn't match certificate's altnames'.
> at /home/wburns/RedHat/jdg-js-client/spec/infinispan_ssl_spec.js:139:27
> at tryCallOne (/home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:37:12)
> at /home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:123:15
> at flush (/home/wburns/RedHat/jdg-js-client/node_modules/asap/raw.js:50:29)
> at nextTickCallbackWith0Args (node.js:419:9)
> at process._tickCallback (node.js:348:13)
> 4) Infinispan TLS/SSL client fails to operate if server name (SNI) and trusted certificate are incorrect
> Message:
> Expected 'certificate signature failure' to be 'CERT_SIGNATURE_FAILURE'.
> Stacktrace:
> Error: Expected 'certificate signature failure' to be 'CERT_SIGNATURE_FAILURE'.
> at /home/wburns/RedHat/jdg-js-client/spec/infinispan_ssl_spec.js:139:27
> at tryCallOne (/home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:37:12)
> at /home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:123:15
> at flush (/home/wburns/RedHat/jdg-js-client/node_modules/asap/raw.js:50:29)
> at nextTickCallbackWith0Args (node.js:419:9)
> at process._tickCallback (node.js:348:13)
> {code}
> So, the error message comparisons need to be adjusted to support other Node versions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ISPN-7313) AbstractFileLookup.lookupFileStrict broken on Windows
by Stefan Engel (JIRA)
[ https://issues.jboss.org/browse/ISPN-7313?page=com.atlassian.jira.plugin.... ]
Stefan Engel updated ISPN-7313:
-------------------------------
Affects Version/s: 8.2.5.Final
> AbstractFileLookup.lookupFileStrict broken on Windows
> -----------------------------------------------------
>
> Key: ISPN-7313
> URL: https://issues.jboss.org/browse/ISPN-7313
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 9.0.0.Beta1, 8.2.5.Final
> Environment: Using Infinispan as JCache provider in Spring Boot (v1.3.5) application on Windows (either IDE (Eclipse) or fat jar).
> Reporter: Stefan Engel
>
> The fix in ISPN-5949 breaks Windows compatibility.
> infinispan.xml is configured in application.properties
> {noformat}
> spring.cache.jcache.config=classpath:spring/infinispan.xml
> {noformat}
> When using Infinispan in a Spring Boot application (fat jar or Eclipse IDE) the following exception is thrown:
> {noformat}
> Caused by: org.infinispan.commons.CacheConfigurationException:
> com.ctc.wstx.exc.WstxIOException: Stream closed
> at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:119)
> at org.infinispan.jcache.embedded.JCacheManager.getConfigurationBuilderHolder(JCacheManager.java:100)
> at org.infinispan.jcache.embedded.JCacheManager.<init>(JCacheManager.java:56)
> at org.infinispan.jcache.embedded.JCachingProvider.createCacheManager(JCachingProvider.java:46)
> at org.infinispan.jcache.AbstractJCachingProvider.getCacheManager(AbstractJCachingProvider.java:67)
> at org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration.createCacheManager(JCacheCacheConfiguration.java:101)
> ...
> {noformat}
> When {{AbstractFileLookup.lookupFileStrict()}} is called in {{JCacheManager.getConfigurationHolder()}} the URI used for infinispan.xml looks something like this:
> * fat jar
> {noformat}
> jar:file:/C:/projects/myapp/myservice-0.0.1.jar!/spring/infinispan.xml
> {noformat}
> * running app from within IDE
> {noformat}
> file:/C:/projects/workspace/myservice/target/classes/spring/infinispan.xml
> {noformat}
> The problem ist now twofold:
> # First this nasty 'C:' in the Windows path breaks the parsing code in {{AbstractFileLookup.lookupFileStrict()}}, as {{lastIndexOf(':')}} cuts the drive letter from the path and not just 'jar:file:' as intended. The resulting {{fileName}} cannot be resolved and {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> {code}
> public InputStream lookupFileStrict(URI uri, ClassLoader cl) throws FileNotFoundException {
> //in case we don't have only file schema, but {{jar:file}} schema too, we have to get rid of all schemas
> int startIndex = uri.toString().lastIndexOf(':');
> String fileName = uri.toString().substring(startIndex + 1);
> return cl.getResourceAsStream(fileName);
> }
> {code}
> # This method gets called too when running from within an IDE (at least Eclipse with Maven integration). But in this case Spring JCacheCacheConfiguration magic (createCachemanager() - configLocation.getURI()) resolves this path to a full path as seen above (not a classpath relative to {{/target/classes}}). As this path ist not on the classpath, {{cl.getResourceAsStream(fileName)}} returns {{null}}.
> In both cases {{lookupFileStrict}} returns {{null}} as {{InputStream}} which in turn leads to the exception mentioned above.
> The old code of {{lookupFileStrict()}}
> {code}
> return new FileInputStream(new File(uri));
> {code}
> works fine from within the IDE, but is broken for a fat jar (ISPN-5949).
> I am currently trying to find a workaround for this. But as far as I can see, the current behaviour (fix or no fix) is going to a problem when developing/running Infinispan enabled applications on Windows.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-29) Security related error messages vary between Node versions
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-29:
------------------------------------
Summary: Security related error messages vary between Node versions
Key: HRJS-29
URL: https://issues.jboss.org/browse/HRJS-29
Project: Infinispan Javascript client
Issue Type: Bug
Reporter: Galder Zamarreño
Currently testsuite works fine with Node 0.10. When running for example with Node 4.x, you get errors like this:
{code}
2) Infinispan TLS/SSL client can operate on data via crypto store trusted encrypted transport
Message:
Error: self signed certificate in certificate chain
Stacktrace:
Error: self signed certificate in certificate chain
at Error (native)
at TLSSocket.<anonymous> (_tls_wrap.js:1016:38)
at emitNone (events.js:67:13)
at TLSSocket.emit (events.js:166:7)
at TLSSocket._finishInit (_tls_wrap.js:585:8)
3) Infinispan TLS/SSL client fails to operate if default server name (SNI) does not match default server realm
Message:
Expected 'Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not cert's CN: untrusted.acme"' to be 'Hostname/IP doesn't match certificate's altnames'.
Stacktrace:
Error: Expected 'Hostname/IP doesn't match certificate's altnames: "Host: localhost. is not cert's CN: untrusted.acme"' to be 'Hostname/IP doesn't match certificate's altnames'.
at /home/wburns/RedHat/jdg-js-client/spec/infinispan_ssl_spec.js:139:27
at tryCallOne (/home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:37:12)
at /home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:123:15
at flush (/home/wburns/RedHat/jdg-js-client/node_modules/asap/raw.js:50:29)
at nextTickCallbackWith0Args (node.js:419:9)
at process._tickCallback (node.js:348:13)
4) Infinispan TLS/SSL client fails to operate if server name (SNI) and trusted certificate are incorrect
Message:
Expected 'certificate signature failure' to be 'CERT_SIGNATURE_FAILURE'.
Stacktrace:
Error: Expected 'certificate signature failure' to be 'CERT_SIGNATURE_FAILURE'.
at /home/wburns/RedHat/jdg-js-client/spec/infinispan_ssl_spec.js:139:27
at tryCallOne (/home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:37:12)
at /home/wburns/RedHat/jdg-js-client/node_modules/promise/lib/core.js:123:15
at flush (/home/wburns/RedHat/jdg-js-client/node_modules/asap/raw.js:50:29)
at nextTickCallbackWith0Args (node.js:419:9)
at process._tickCallback (node.js:348:13)
{code}
So, the error message comparisons need to be adjusted to support other Node versions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-28) Node kill pkill commands failing in some envs
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-28:
------------------------------------
Summary: Node kill pkill commands failing in some envs
Key: HRJS-28
URL: https://issues.jboss.org/browse/HRJS-28
Project: Infinispan Javascript client
Issue Type: Enhancement
Affects Versions: 0.3.0
Reporter: Galder Zamarreño
On certain environments (e.g. Ubuntu), tests involving killing nodes are failing with errors like this:
{code}
1) Infinispan cluster client can failover when nodes crash
Message:
Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
Stacktrace:
Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
at ChildProcess.exithandler (child_process.js:213:12)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (internal/child_process.js:821:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
...
5) Infinispan xsite cluster client can manually switch and fail over sites
Message:
Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
Stacktrace:
Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
at ChildProcess.exithandler (child_process.js:213:12)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (internal/child_process.js:821:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
{code}
After doing some debugging, we discovered that the error itself contains this info:
{code}
{"killed":false,"code":null,"signal":"SIGKILL","cmd":"/bin/sh -c pkill -9 -f '.*java.*node4 .*'"}
{code}
According to the docu:
{code}
If the process terminated normally, code is the final exit code of the process, otherwise null. If the process terminated due to receipt of a signal, signal is the string name of the signal, otherwise null.
{code}
So, it would appear that {{pkill}} is killing itself?
The easiest workaround here might be to ignore any errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (HRJS-28) Node kill pkill commands failing in some envs
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/HRJS-28?page=com.atlassian.jira.plugin.sy... ]
Galder Zamarreño updated HRJS-28:
---------------------------------
Status: Open (was: New)
> Node kill pkill commands failing in some envs
> ---------------------------------------------
>
> Key: HRJS-28
> URL: https://issues.jboss.org/browse/HRJS-28
> Project: Infinispan Javascript client
> Issue Type: Enhancement
> Affects Versions: 0.3.0
> Reporter: Galder Zamarreño
>
> On certain environments (e.g. Ubuntu), tests involving killing nodes are failing with errors like this:
> {code}
> 1) Infinispan cluster client can failover when nodes crash
> Message:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
> Stacktrace:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node4 .*'
> at ChildProcess.exithandler (child_process.js:213:12)
> at emitTwo (events.js:87:13)
> at ChildProcess.emit (events.js:172:7)
> at maybeClose (internal/child_process.js:821:16)
> at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
> ...
> 5) Infinispan xsite cluster client can manually switch and fail over sites
> Message:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
> Stacktrace:
> Error: Command failed: /bin/sh -c pkill -9 -f '.*java.*node-site-a .*'
> at ChildProcess.exithandler (child_process.js:213:12)
> at emitTwo (events.js:87:13)
> at ChildProcess.emit (events.js:172:7)
> at maybeClose (internal/child_process.js:821:16)
> at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
> {code}
> After doing some debugging, we discovered that the error itself contains this info:
> {code}
> {"killed":false,"code":null,"signal":"SIGKILL","cmd":"/bin/sh -c pkill -9 -f '.*java.*node4 .*'"}
> {code}
> According to the docu:
> {code}
> If the process terminated normally, code is the final exit code of the process, otherwise null. If the process terminated due to receipt of a signal, signal is the string name of the signal, otherwise null.
> {code}
> So, it would appear that {{pkill}} is killing itself?
> The easiest workaround here might be to ignore any errors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months