September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFCORE-1836: -------------------------------------- [~kabirkhan] Hmm - it might, but I doubt it. I'll try. If it works, I'll close this jira. > Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-1836 > URL: https://issues.jboss.org/browse/WFCORE-1836 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. > This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Lin Gao commented on WFCORE-1351: --------------------------------- I tried to use privileged action to create Endpoint using commit at: https://github.com/gaol/jboss-remote-naming/commit/340aebc46459b869f1c821... . The first 4 Permission check exceptions are gone, however, the last 2 permission check exceptions are still there: 1. new RuntimePermission("accessDeclaredMembers") -> [^5-no-suppressAccessChecks-permission.stracktrace] 2. new java.lang.reflect.ReflectPermission("suppressAccessChecks") -> Test Pass > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha10 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2105) Add support for SLF4J logger

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2105?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2105: -------------------------------- The preferred logger impl can be defined with system property "jgroups.log_class", e.g. {{-Djgroups.log_class=org.jgroups.logging.Slf4jLogImpl}}. > Add support for SLF4J logger > ---------------------------- > > Key: JGRP-2105 > URL: https://issues.jboss.org/browse/JGRP-2105 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Support sl4j logging -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7224: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-7224 > URL: https://issues.jboss.org/browse/WFLY-7224 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log: > {code} > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}, > "rolled-back" => true > } > {code} > Exception in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > 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) > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64) > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49) > at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} > The same happens for mapped-regex-realm-mapper. > Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Description: We need to remove the following block from SecurityRealmResourceDefinition: - {code} static { //register the Openssl Provider, if possible //not really sure if this is the best place for it try { OpenSSLProvider.register(); DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); } catch (Throwable t){ DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); } } {code} Registration will then be possible within the Elytron subsystem configuration. > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Priority: Blocker (was: Major) > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1802: ---------------------------------------- Assignee: Darran Lofthouse > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1315) Expired fact with activationCount > 0 are not evicted from objectstore

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1315: ----------------------------------- Summary: Expired fact with activationCount > 0 are not evicted from objectstore Key: DROOLS-1315 URL: https://issues.jboss.org/browse/DROOLS-1315 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Mario Fusco Fix For: 7.0.0.Final Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual. Sized-down reproducer will be submitted at a later time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1310?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1310: -------------------------------- Priority: Major (was: Minor) > Expired fact with activationCount > 0 are not evicted from objectstore > ---------------------------------------------------------------------- > > Key: DROOLS-1310 > URL: https://issues.jboss.org/browse/DROOLS-1310 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.CR2 > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > Attachments: RuleTest.java > > > Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual. > Sized-down reproducer will be submitted at a later time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016