[JBoss JIRA] (WFLY-1319) Thread security context stuck with invalid credentials after authentication failure
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1319?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1319:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1489899, https://bugzilla.redhat.com/show_bug.cgi?id=1480670, https://bugzilla.redhat.com/show_bug.cgi?id=1480711
Bugzilla Update: Perform
> Thread security context stuck with invalid credentials after authentication failure
> -----------------------------------------------------------------------------------
>
> Key: WFLY-1319
> URL: https://issues.jboss.org/browse/WFLY-1319
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Environment: JBoss AS 7.1.1-FINAL on Win2K3 Server and Linux, 64-bit JRE 7
> Reporter: Martin Maierhofer
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
>
> We came across this in an environment of ours that uses a custom login module, but if I read the code correctly, this is a more general problem: if an authentication failure occurs while handling an EJB method, then the security context for the thread is not reset correctly, and subsequent uses of the thread for anonymous methods (e.g. timers) use the incorrect credentials.
> I suspect the problem lies in SimpleSecurityManager's push() implementation, which is invoked from the SecurityContextInterceptor as follows:
> {code}
> @Override
> public Object processInvocation(final InterceptorContext context) throws Exception {
> // TODO - special cases need to be handled where SecurityContext not established or minimal unauthenticated principal context instead.
> doPrivileged(pushAction);
> try {
> return context.proceed();
> } finally {
> doPrivileged(popAction);
> }
> }
> {code}
> If the pushAction throws an exception, then the popAction is never invoked. SimpleSecurityManager's push action starts off with
> {code}
> public void push(final String securityDomain) {
> // TODO - Handle a null securityDomain here? Yes I think so.
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> contexts.push(previous);
> SecurityContext current = establishSecurityContext(securityDomain);
> {code}
> If an exception is subsequently raised, then the thread's security context is never reset (and previous is never popped off the "contexts" stack either).
> If the same thread is subsequently used in a timer invocation that is supposed to run without a principal, the old security context is still active in the thread, and will be used incorrectly. (In our case leading to the same authentication exception over and over.)
> I was able to successfully work around this issue by catching exceptions in push() and invoking pop() in the catch block, before rethrowing the exception.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-9325:
-------------------------------------
[~brian.stansberry] It can be configured to do that, but it's currently not used. There is a {{cleanServerBaseDir}} property which takes a path or {{setupCleanServerBaseDir}} property which takes boolean and defaults to temporary directory. If either if these is set the {{jboss.server.base.dir}} directory would be copied to a new directory. Otherwise it would just default to using the {{jboss.server.base.dir}} directory.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9325:
----------------------------------------
The -Dci-cleanup=true flag wasn't being set on a number of jobs testing core 3.x/3.0.x PRs. I corrected that.
[~jamezp] If that flag is set, would arq create the expected structure and copy in the config files?
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-9325:
-------------------------------------
The {{<property name="jbossArguments">-Djboss.server.base.dir=path</property>}} could be used in the {{arquillian.xml}}.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9325) Reduce on-disk size and copying in the test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9325?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9325:
----------------------------------------
The domain testsuite uses our standard feature of allowing a server to declare its jboss.server.base.dir / jboss.server.domain.dir and thus only creates those directories for custom installations, relying on a single install in testsuite/domain for everything else (with, IIRC, that single install not copying in the modules). Perhaps WFARQ could make that easy to do elsewhere. Testing a custom franken-install is ok if necessary but trying instead to utilize the footprint-slimming features we provide for our users is a form of eating our own dog food.
The CI cleanup switch I mentioned
is at https://github.com/wildfly/wildfly/commit/60c6a83eeaad726cb27e6f1b48c6f80... and was meant to help CI (or us if we turn it on locally) to clean out no longer needed data at the end of each testsuite module. If we are still showing GBs of data accumulating in these AS copies over the course of a CI run, then something isn't working right with that.
> Reduce on-disk size and copying in the test suite
> -------------------------------------------------
>
> Key: WFLY-9325
> URL: https://issues.jboss.org/browse/WFLY-9325
> Project: WildFly
> Issue Type: Enhancement
> Components: Build System, Test Suite
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
>
> The test suite takes up large amounts of disk space (over 2.7GB) during build. This causes overhead for copying and bogs down test runs and CI. Find ways to mitigate this.
> First approach is to use Maven refs instead of fixed JARs in the build process:
> {code:diff}
> diff --git a/pom.xml b/pom.xml
> index fb2b68c..5805471 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -252,8 +252,8 @@
> <linkXRef>false</linkXRef>
>
> <server.output.dir.prefix>wildfly</server.output.dir.prefix>
> - <wildfly.build.output.dir>dist/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> - <wildfly.web.build.output.dir>servlet-dist/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
> + <wildfly.build.output.dir>build/target/${server.output.dir.prefix}-${jboss.as.release.version}</wildfly.build.output.dir>
> + <wildfly.web.build.output.dir>servlet-build/target/${server.output.dir.prefix}-servlet-${jboss.as.release.version}</wildfly.web.build.output.dir>
>
> <!--
> See ChildFirstClassLoaderBuilder in model-test for the explanation of the org.jboss.model.test.cache.root and org.jboss.model.test.classpath.cache properties.
> {code}
> This saves a bit of space but copied images are still taking upwards of 55MB each, and there are very many copies; consider this example from {{testsuite/integration/iiop/target}}:
> {noformat}
> 30M jbossas
> 55M jbossas-iiop-client
> 55M jbossas-iiop-server
> 55M jbossas-iiop-ssl-client
> 55M jbossas-iiop-ssl-legacy-server
> 55M jbossas-iiop-ssl-server
> {noformat}
> Within a typical copy (after the above patch), about half of the data is in {{bin}} and half is in {{standalone}}. In {{bin}}, the dominating files are:
> * {{2.2M wildfly-elytron-tool.jar}}
> * {{7.2M client/jboss-cli-client.jar}}
> * {{17M client/jboss-client.jar}}
> In {{standalone}}, the dominator is:
> * {{25M data/activemq}} (mostly journal files but also the {{bindings}} file)
> Together these four areas cover 51.4MB of the 55MB in each IIOP server copy.
> In other areas, big users include {{standalone_xml_history}}, which can be as large as 67MB. Disabling the across the board could help.
> We're also making over 50 copies of the {{docs}} directory at 2.3M per instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3267) Authorization identity forwarding not exposed to configuration
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3267?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-3267:
---------------------------------
Fix Version/s: 3.0.2.CR1
> Authorization identity forwarding not exposed to configuration
> --------------------------------------------------------------
>
> Key: WFCORE-3267
> URL: https://issues.jboss.org/browse/WFCORE-3267
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jason Greene
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 3.0.2.CR1, 3.0.2.Final
>
>
> As part of EAP7-284, Elytron was designed for and contains implementation to support trusted use of identities between peers in addition to credential forwarding. Cases in which one would prefer this approach include:
> * Scenarios where the user has requirements to not send passwords over the wire. Notably credential forwarding requires TLS and/or secure networks
> * Setups where an authentication type that does not support credential forwarding are used (credential forwarding is limited to Plain, Form, and OAuth, all other mechanisms, including the out of the box Digest auth of EAP are not)
> * Environments where its desired to limit which systems are allowed to receive requests which are propagated
> Due to an oversight this capability was not properly wired to the server configuration (nor a config method on the Elytron API).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3266) Simple permission mapper can't represent wildcards or spaces
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3266?page=com.atlassian.jira.plugi... ]
Jason Greene updated WFCORE-3266:
---------------------------------
Fix Version/s: 3.0.2.CR1
3.0.2.Final
> Simple permission mapper can't represent wildcards or spaces
> ------------------------------------------------------------
>
> Key: WFCORE-3266
> URL: https://issues.jboss.org/browse/WFCORE-3266
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jason Greene
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 3.0.2.CR1, 3.0.2.Final
>
>
> The inability of the simple-permission-mapper to handle wildcards forces the user to utilize complex logical permission mapper chains to achieve common use cases. This makes simple changes, such as adding an additional permission to a user unnecessarily complex. In addition to construction complexity, modifications performed by non-experts are likely to lead to unintended behavior, including accidentally granting permissions to a user that should not have them.
> This is readily apparent by even our default configuration requiring the use of 3 permission mappers to handle the basic case of denying anonymous users and allowing everyone else.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months