[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7225?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7225:
-------------------------------------
This issue is resolved with the PR [1] for https://issues.jboss.org/browse/WFLY-7224
[1] https://github.com/wildfly-security/elytron-subsystem/pull/244
> Writing wrong realm-mapper to security-domain causes failures after reload
> --------------------------------------------------------------------------
>
> Key: WFLY-7225
> URL: https://issues.jboss.org/browse/WFLY-7225
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
>
> In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly.
> Suggestion:
> Writing wrong realm-mapper to security-domain should be denied.
> Issue can be related to JBEAP-6214.
> Exceptions in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) 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
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "SomeSecurityDomain")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("simple-regex-realm-mapper" => "SomeRealmMapper")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ...
> ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7225?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7225:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Writing wrong realm-mapper to security-domain causes failures after reload
> --------------------------------------------------------------------------
>
> Key: WFLY-7225
> URL: https://issues.jboss.org/browse/WFLY-7225
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
>
> In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly.
> Suggestion:
> Writing wrong realm-mapper to security-domain should be denied.
> Issue can be related to JBEAP-6214.
> Exceptions in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) 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
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "SomeSecurityDomain")
> ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}
> 07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("simple-regex-realm-mapper" => "SomeRealmMapper")
> ]) - failure description: {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> ...
> ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-7229:
------------------------------------
[~micnowak1] I'm not sure why you need to disable server-side invalidation. There are two standard mechanisms for auto-invalidating sessions:
# Per-session, via HttpSession.setMaxInactiveInterval(20 * 60);
# Globally, via web.xml:
{code:xml}
<session-config>
<session-timeout>20</session-timeout>
</session-config>
{code}
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[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)
9 years, 2 months
[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)
9 years, 2 months
[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)
9 years, 2 months
[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)
9 years, 2 months