April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8533) SecurityIdentityUtils#getSecurityIdentity() should get security domain within a privileged block

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-8533?page=com.atlassian.jira.plugin.... ] Ivo Studensky updated WFLY-8533: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9916, https://github.com/wildfly-security-incubator/wildfly/pull/181 (was: https://github.com/wildfly/wildfly/pull/9916) > SecurityIdentityUtils#getSecurityIdentity() should get security domain within a privileged block > ------------------------------------------------------------------------------------------------ > > Key: WFLY-8533 > URL: https://issues.jboss.org/browse/WFLY-8533 > Project: WildFly > Issue Type: Bug > Components: EE > Affects Versions: 11.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > {{org.jboss.as.ee.concurrent.SecurityIdentityUtils#getSecurityIdentity()}} calls {{SecurityDomain.getCurrent()}} in order to get a security domain. {{SecurityDomain.getCurrent()}} then needs a {{ElytronPermission("getSecurityDomain")}} in order to pass if Security Manager is enabled. > As {{SecurityIdentityUtils#getSecurityIdentity()}} is a private static method and it is invoked from package protected static methods only, I think it should be safe to wrap the {{SecurityDomain.getCurrent()}} invocation by the privileged block there. > See the stacktrace catched by {{EEConcurrencySuspendTestCase}}: > {noformat} > 2017-04-07 11:27:09,445 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ee-suspend/ShutdownServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.wildfly.security.permission.ElytronPermission" "getSecurityDomain")" in code source "(vfs:/content/ee-suspend.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ee-suspend.war" 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 org.wildfly.security.auth.server.SecurityDomain.getCurrent(SecurityDomain.java:154) > at org.jboss.as.ee.concurrent.SecurityIdentityUtils.getSecurityIdentity(SecurityIdentityUtils.java:66) > at org.jboss.as.ee.concurrent.SecurityIdentityUtils.doIdentityWrap(SecurityIdentityUtils.java:57) > at org.jboss.as.ee.concurrent.ManagedExecutorServiceImpl.execute(ManagedExecutorServiceImpl.java:71) > at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.execute(ManagedExecutorServiceAdapter.java:97) > at org.jboss.as.test.integration.ee.suspend.ShutdownServlet.doGet(ShutdownServlet.java:47) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:46) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1706) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1706) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1706) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1706) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:110) > at java.security.AccessController.doPrivileged(Native Method) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1519?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1519: ---------------------------------------- Some background [here|https://issues.jboss.org/browse/DROOLS-1404?focusedCommentId=1334823...]. > (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1519 > URL: https://issues.jboss.org/browse/DROOLS-1519 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > See: > http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... > The ($v == var) filters much later causing a scaling loss. > Investigate if drools can avoid that problem and make the slow one as fast as the fast one. > We don't want to have to rewrite all our rules to take advantage of this speedup and educate all our users to prefer one way over another, if and only if we can avoid it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1519?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1519: ------------------------------------- Description: See: http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... The ($v == var) filters much later causing a scaling loss. Investigate if drools can avoid that problem and make the slow one as fast as the fast one. We don't want to have to rewrite all our rules to take advantage of this speedup and educate all our users to prefer one way over another, if and only if we can avoid it. was: See: http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... The ($v == var) filters much later causing a scaling loss. Investigate if drools can avoid that problem and make the slow one as fast as the fast one? so we don't have to rewrite all our rules to take advantage of this speedup. > (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1519 > URL: https://issues.jboss.org/browse/DROOLS-1519 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > See: > http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... > The ($v == var) filters much later causing a scaling loss. > Investigate if drools can avoid that problem and make the slow one as fast as the fast one. > We don't want to have to rewrite all our rules to take advantage of this speedup and educate all our users to prefer one way over another, if and only if we can avoid it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1519?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1519: ------------------------------------- Description: See: http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... The ($v == var) filters much later causing a scaling loss. Investigate if drools can avoid that problem and make the slow one as fast as the fast one? so we don't have to rewrite all our rules to take advantage of this speedup. was: See: http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... The ($v == var) filters much later causing a serious scaling loss. Investigate if drools can avoid that problem and make the slow one as fast as the fast one? so we don't have to rewrite all our rules to take advantage of this speedup. > (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? > ------------------------------------------------------------------------------------------ > > Key: DROOLS-1519 > URL: https://issues.jboss.org/browse/DROOLS-1519 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > Priority: Critical > > See: > http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... > The ($v == var) filters much later causing a scaling loss. > Investigate if drools can avoid that problem and make the slow one as fast as the fast one? > so we don't have to rewrite all our rules to take advantage of this speedup. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1519) (var == $v) is faster than ($v == var) and scales much better: can they both be that fast?

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1519: ---------------------------------------- Summary: (var == $v) is faster than ($v == var) and scales much better: can they both be that fast? Key: DROOLS-1519 URL: https://issues.jboss.org/browse/DROOLS-1519 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 6.5.0.Final Reporter: Geoffrey De Smet Assignee: Mario Fusco Priority: Critical See: http://stackoverflow.com/questions/43282665/why-does-the-order-of-how-we-... The ($v == var) filters much later causing a serious scaling loss. Investigate if drools can avoid that problem and make the slow one as fast as the fast one? so we don't have to rewrite all our rules to take advantage of this speedup. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1066) Add a GSSCredential CredentialSource

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1066?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1066: ---------------------------------- Fix Version/s: 2.0.0.Alpha1 (was: 1.1.0.Beta36) > Add a GSSCredential CredentialSource > ------------------------------------ > > Key: ELY-1066 > URL: https://issues.jboss.org/browse/ELY-1066 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credentials > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 2.0.0.Alpha1 > > > Initially this should be minimal / no configuration to make a GSSCrdential available if the local user has a Kerberos ticket - at a later point we can review adding additional config such as client keytabs etc... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1065) Update GssapiClient to use CallbackHandler to obtain credential.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1065?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1065: ---------------------------------- Priority: Major (was: Blocker) > Update GssapiClient to use CallbackHandler to obtain credential. > ---------------------------------------------------------------- > > Key: ELY-1065 > URL: https://issues.jboss.org/browse/ELY-1065 > Project: WildFly Elytron > Issue Type: Enhancement > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > The mechanism should attempt to obtain a credential from the CBH if one not supplied in the properties. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1065) Update GssapiClient to use CallbackHandler to obtain credential.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1065?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1065: ---------------------------------- Fix Version/s: 2.0.0.Alpha1 (was: 1.1.0.Beta36) > Update GssapiClient to use CallbackHandler to obtain credential. > ---------------------------------------------------------------- > > Key: ELY-1065 > URL: https://issues.jboss.org/browse/ELY-1065 > Project: WildFly Elytron > Issue Type: Enhancement > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > > The mechanism should attempt to obtain a credential from the CBH if one not supplied in the properties. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1069) GSSAPI SASL mechanism should not require a Principal

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1069?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1069: ---------------------------------- Description: Also client credentials should be optional. > GSSAPI SASL mechanism should not require a Principal > ---------------------------------------------------- > > Key: ELY-1069 > URL: https://issues.jboss.org/browse/ELY-1069 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta36 > > > Also client credentials should be optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1069) GSSAPI SASL mechanism should not require a Principal

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1069: ------------------------------------- Summary: GSSAPI SASL mechanism should not require a Principal Key: ELY-1069 URL: https://issues.jboss.org/browse/ELY-1069 Project: WildFly Elytron Issue Type: Bug Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta36 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017