[JBoss JIRA] (WFLY-12455) Update permission names in tests to fix failures that occur with the security manager enabled after the JBoss Jakarta JACC and JASPI upgrades
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-12455?page=com.atlassian.jira.plugin... ]
Farah Juma updated WFLY-12455:
------------------------------
Summary: Update permission names in tests to fix failures that occur with the security manager enabled after the JBoss Jakarta JACC and JASPI upgrades (was: Update permission names in tests to fix failures that occur with the security manager enabled)
> Update permission names in tests to fix failures that occur with the security manager enabled after the JBoss Jakarta JACC and JASPI upgrades
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12455
> URL: https://issues.jboss.org/browse/WFLY-12455
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Major
>
> The upgrades to JBoss Jakarta JACC 2.0.0.CR1 and JBoss Jakarta JASPI fork 2.0.0.CR1 are causing the following test failures with the security manager enabled:
> PolicyContextTestCase.testHttpServletRequestFromPolicyContext
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "setPolicy")" in code source "(vfs:/content/ear-jacc-context.ear/ear-jacc-context.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ear-jacc-context.ear.ear-jacc-context.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at javax.security.jacc.PolicyContext.checkSetPolicyPermission(PolicyContext.java:237)
> at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:226)
> {code}
>
> AuthenticationPolicyContextTestCase.test
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "setPolicy")" in code source "(vfs:/content/picketlink-sts-ws.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.picketlink-sts-ws.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at javax.security.jacc.PolicyContext.checkSetPolicyPermission(PolicyContext.java:237)
> at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:226)
> {code}
> The above two failures are occurring because {{PolicyContext.getContext}} now checks for the "setPolicy" permission instead of the "getPolicy" permission:
> PolicyContext.getContext before JACC upgrade:
> https://github.com/jboss/jboss-jacc-api_spec/blob/master/src/main/java/ja...
> PolicyContext.getContext after JACC upgrade:
> https://github.com/jboss/jboss-jakarta-jacc-api_spec/blob/6b5f2641b115239...
>
> DynamicJaspiTestCase.testCalls
> {code}
> &#27;[0m&#27;[31m09:18:43,183 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ConfiguredJaspiTestCase/: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getProperty.authconfigprovider.factory")" in code source "(vfs:/content/ConfiguredJaspiTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ConfiguredJaspiTestCase.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
> at javax.security.auth.message.config.AuthConfigFactory.checkPermission(AuthConfigFactory.java:166)
> at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:201)
> at org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.register(JaspiConfigurationBuilder.java:106)
> {code}
>
> The above failure occurs because {{AuthConfigFactory.getFactory}} now checks for the "getProperty.authconfigprovider.factory" permission instead of the "getFactory" permission:
> AuthConfigFactory.getFactory before JASPI upgrade:
> https://github.com/jboss/jboss-jaspi-api_spec/blob/jboss-jaspi-api_1.1_sp...
> AuthConfigFactory.getFactory after JASPI upgrade:
> https://github.com/jboss/jboss-jakarta-jaspi-api_spec/blob/3e290bd05a6518...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (WFLY-12455) Update permission names in tests to fix failures that occur with the security manager enabled
by Farah Juma (Jira)
Farah Juma created WFLY-12455:
---------------------------------
Summary: Update permission names in tests to fix failures that occur with the security manager enabled
Key: WFLY-12455
URL: https://issues.jboss.org/browse/WFLY-12455
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: Farah Juma
Assignee: Farah Juma
The upgrades to JBoss Jakarta JACC 2.0.0.CR1 and JBoss Jakarta JASPI fork 2.0.0.CR1 are causing the following test failures with the security manager enabled:
PolicyContextTestCase.testHttpServletRequestFromPolicyContext
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "setPolicy")" in code source "(vfs:/content/ear-jacc-context.ear/ear-jacc-context.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ear-jacc-context.ear.ear-jacc-context.jar" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at javax.security.jacc.PolicyContext.checkSetPolicyPermission(PolicyContext.java:237)
at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:226)
{code}
AuthenticationPolicyContextTestCase.test
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "setPolicy")" in code source "(vfs:/content/picketlink-sts-ws.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.picketlink-sts-ws.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at javax.security.jacc.PolicyContext.checkSetPolicyPermission(PolicyContext.java:237)
at javax.security.jacc.PolicyContext.getContext(PolicyContext.java:226)
{code}
The above two failures are occurring because {{PolicyContext.getContext}} now checks for the "setPolicy" permission instead of the "getPolicy" permission:
PolicyContext.getContext before JACC upgrade:
https://github.com/jboss/jboss-jacc-api_spec/blob/master/src/main/java/ja...
PolicyContext.getContext after JACC upgrade:
https://github.com/jboss/jboss-jakarta-jacc-api_spec/blob/6b5f2641b115239...
DynamicJaspiTestCase.testCalls
{code}
&#27;[0m&#27;[31m09:18:43,183 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /ConfiguredJaspiTestCase/: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.security.SecurityPermission" "getProperty.authconfigprovider.factory")" in code source "(vfs:/content/ConfiguredJaspiTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ConfiguredJaspiTestCase.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:294)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:191)
at javax.security.auth.message.config.AuthConfigFactory.checkPermission(AuthConfigFactory.java:166)
at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:201)
at org.wildfly.security.auth.jaspi.JaspiConfigurationBuilder.register(JaspiConfigurationBuilder.java:106)
{code}
The above failure occurs because {{AuthConfigFactory.getFactory}} now checks for the "getProperty.authconfigprovider.factory" permission instead of the "getFactory" permission:
AuthConfigFactory.getFactory before JASPI upgrade:
https://github.com/jboss/jboss-jaspi-api_spec/blob/jboss-jaspi-api_1.1_sp...
AuthConfigFactory.getFactory after JASPI upgrade:
https://github.com/jboss/jboss-jakarta-jaspi-api_spec/blob/3e290bd05a6518...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (AG-122) Fix travis setup for JDK8
by Luis Barreiro (Jira)
Luis Barreiro created AG-122:
--------------------------------
Summary: Fix travis setup for JDK8
Key: AG-122
URL: https://issues.jboss.org/browse/AG-122
Project: Agroal
Issue Type: Task
Components: build
Reporter: Luis Barreiro
Assignee: Luis Barreiro
JDK8 is not available on all kinds of travis workers.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (DROOLS-4335) Allow to define sequence mode in kmodule.xml
by Stetson Robinson (Jira)
[ https://issues.jboss.org/browse/DROOLS-4335?page=com.atlassian.jira.plugi... ]
Stetson Robinson commented on DROOLS-4335:
------------------------------------------
In summary from Mario in chat:
* Behavior: Set the sequential mode system property for all KIE bases in all projects, or set it in the project kmodule.xml file for the KIE base in just that project.
* Doc impact:
** Add the `sequential` attribute to the list of [KIE base attributes|https://access.redhat.com/documentation/en-us/red_hat_process_...] in the packaging doc (sequential="true" or false, default is false).
** Note this in the [Rule base config|https://access.redhat.com/documentation/en-us/red_hat_process_auto...] section of the decision engine doc, and maybe the seq mode section that follows.
>From our chat:
Mario Fusco
,
11:19 AM
,
the main difference of using kmodule.xml vs system property is that the second applies for the whole jvm
if you have only one kbase this is not a problem
but if you have more than one you may want to have some of them running in sequential mode and some else not
and you can selectively choose which one is sequential in the kmodule.xml file this way
and then we should just mention that new attribute in that table there
agreed?
Stetson Robinson
,
11:23 AM
,
Got it. So to confirm, set the property in kmodule.xml for a single KIE base in a specific project, or set the property in system propertys for all KIE bases in all projects in your product distribution. Correct?
Mario Fusco
,
11:23 AM
,
correct
Stetson Robinson
,
11:24 AM
,
And the exact format in the kmodule.xml is sequential="true" (or "false"), and by default, it's "false", yes?
Mario Fusco
,
11:25 AM
,
yep, correct
> Allow to define sequence mode in kmodule.xml
> --------------------------------------------
>
> Key: DROOLS-4335
> URL: https://issues.jboss.org/browse/DROOLS-4335
> Project: Drools
> Issue Type: Feature Request
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.25.0.Final
>
>
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (ELY-1869) Upgrade jboss-modules to 1.9.1.Final
by Diana Vilkolakova (Jira)
Diana Vilkolakova created ELY-1869:
--------------------------------------
Summary: Upgrade jboss-modules to 1.9.1.Final
Key: ELY-1869
URL: https://issues.jboss.org/browse/ELY-1869
Project: WildFly Elytron
Issue Type: Component Upgrade
Reporter: Diana Vilkolakova
Upgrade jboss-modules to match the version in WildFly Core. There is no specific problem occuring now, but might be good to bring the version up to date and run tests with newer version.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (DROOLS-1280) further document state machine, thread-safety and include diagrams
by Stetson Robinson (Jira)
[ https://issues.jboss.org/browse/DROOLS-1280?page=com.atlassian.jira.plugi... ]
Stetson Robinson updated DROOLS-1280:
-------------------------------------
Description:
Spin-off remaining linked documentation work from [DROOLS-1272] for:
Include docs on state machine and thread safety
Ensure the N&N section describing state machine and thread-safety is correctly reflected in section of the manual.
[From [~stetson.robinson]]
Confirmed with Mark and Mario that the state machine diagram does not belong in the docs, at least for now. Note from Mark in chat: "all they need to know is 1) there three interacting threads: user, timer and engine 2) we have a state machine based algorithm to efficient co-ordinate those threads and ensure thread safety."
Attached the state machine diagrams from Mark for future ref, if needed.
was:
Spin-off remaining linked documentation work from [DROOLS-1272] for:
Include docs on state machine and thread safety
Ensure the N&N section describing state machine and thread-safety is correctly reflected in section of the manual.
[From [~stetson.robinson]]
Confirmed with Mark and Mario that the state machine diagram does not belong in the docs. Note from Mark in chat: "all they need to know is 1) there three interacting threads: user, timer and engine 2) we have a state machine based algorithm to efficient co-ordinate those threads and ensure thread safety."
> further document state machine, thread-safety and include diagrams
> ------------------------------------------------------------------
>
> Key: DROOLS-1280
> URL: https://issues.jboss.org/browse/DROOLS-1280
> Project: Drools
> Issue Type: Enhancement
> Components: docs
> Reporter: Matteo Mortari
> Assignee: Stetson Robinson
> Priority: Minor
> Attachments: fireLoop.png, fireUntilHalt and fireAllRules.png, restHandler.png, waitAndEnter.png
>
>
> Spin-off remaining linked documentation work from [DROOLS-1272] for:
> Include docs on state machine and thread safety
> Ensure the N&N section describing state machine and thread-safety is correctly reflected in section of the manual.
> [From [~stetson.robinson]]
> Confirmed with Mark and Mario that the state machine diagram does not belong in the docs, at least for now. Note from Mark in chat: "all they need to know is 1) there three interacting threads: user, timer and engine 2) we have a state machine based algorithm to efficient co-ordinate those threads and ensure thread safety."
> Attached the state machine diagrams from Mark for future ref, if needed.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months
[JBoss JIRA] (DROOLS-1280) further document state machine, thread-safety and include diagrams
by Stetson Robinson (Jira)
[ https://issues.jboss.org/browse/DROOLS-1280?page=com.atlassian.jira.plugi... ]
Stetson Robinson updated DROOLS-1280:
-------------------------------------
Attachment: fireLoop.png
fireUntilHalt and fireAllRules.png
restHandler.png
waitAndEnter.png
> further document state machine, thread-safety and include diagrams
> ------------------------------------------------------------------
>
> Key: DROOLS-1280
> URL: https://issues.jboss.org/browse/DROOLS-1280
> Project: Drools
> Issue Type: Enhancement
> Components: docs
> Reporter: Matteo Mortari
> Assignee: Stetson Robinson
> Priority: Minor
> Attachments: fireLoop.png, fireUntilHalt and fireAllRules.png, restHandler.png, waitAndEnter.png
>
>
> Spin-off remaining linked documentation work from [DROOLS-1272] for:
> Include docs on state machine and thread safety
> Ensure the N&N section describing state machine and thread-safety is correctly reflected in section of the manual.
> [From [~stetson.robinson]]
> Confirmed with Mark and Mario that the state machine diagram does not belong in the docs, at least for now. Note from Mark in chat: "all they need to know is 1) there three interacting threads: user, timer and engine 2) we have a state machine based algorithm to efficient co-ordinate those threads and ensure thread safety."
> Attached the state machine diagrams from Mark for future ref, if needed.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
5 years, 6 months