[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2214?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2214:
---------------------------
Attachment: CertficateCNMatcher.java
> SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
> ------------------------------------------------------------
>
> Key: JGRP-2214
> URL: https://issues.jboss.org/browse/JGRP-2214
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.5
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.6
>
> Attachments: CertficateCNMatcher.java
>
>
> In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
> However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
> If this is not the case, terminate the SSL connection.
> Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 8/29/17 2:49 AM:
------------------------------------------------------------------------
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.
But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.
I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.
On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via eclipse or startup bat.
I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.
I believe there is a bug here.
- The behavior is not deterministic
- The behavior typically demonstrates the class isolation that the module architecture is working most of the time
- It also shows that sometimes as a side effect of depending org.jboss.logmanager you module class loader is soiled but the log4j packages.
And the module architecture apparently should allow a module A (our routing module) to depend on a module B (org.jboss.logmanager) without being forced to be corruped by all the dependnecies e.g module C (org.jboss.log4j) that are transitive to module B.
And this behavior seems to work most of the time but not all of the time.
- I believe I will ask for permission to give you a configuration with this router logger.
To demonstrate the issue on startup.
Because then you would quite clearly see that there is a problem here.
Many thanks for all the Input.
was (Author: nuno.godinhomatos):
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.
But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.
I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.
On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via eclipse or startup bat.
I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.
Soithinkthereismost definitely about here.
Many thanks for all the Input.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JGRP-2214) SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
by Bela Ban (JIRA)
Bela Ban created JGRP-2214:
------------------------------
Summary: SSL_KEY_EXCHANGE: add hook to verify SSL session credentials
Key: JGRP-2214
URL: https://issues.jboss.org/browse/JGRP-2214
Project: JGroups
Issue Type: Feature Request
Affects Versions: 4.0.5
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.6
In {{SSL_KEY_EXCHANGE}}, when an SSL session has been established, we're sure that the credentials of the server and client are OK.
However, an additional check might be required, e.g. that the CN in the peer's certificate always matches a given pattern, or that the org always is "IBM" (for example).
If this is not the case, terminate the SSL connection.
Todo: add the fully qualified name of a class and an argument (e.g. the pattern). An instance of the class will be created and initialized with the pattern. When an SSL session has been created ({{connect()}} on the client, {{accept()}} on the server), the {{verify()}} method in the instance is called and it needs to throw a {{SecurityException}} if the session cannot be accepted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9273) Referral mode 'throw' for searching groups in legacy LDAP realm causes NPE
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9273?page=com.atlassian.jira.plugin.... ]
Jiri Ondrusek updated WFLY-9273:
--------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2750 (was: https://github.com/wildfly/wildfly-core/pull/2749)
> Referral mode 'throw' for searching groups in legacy LDAP realm causes NPE
> --------------------------------------------------------------------------
>
> Key: WFLY-9273
> URL: https://issues.jboss.org/browse/WFLY-9273
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.CR1
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: eap72
>
> When referral mode 'throw' is configured for LDAP outbound connection which is used by legacy LDAP security realm and its groups are assigned through principal-to-group LDAP authorization then it finishes with NPE. It causes that Management Console returns status 500 when referral mode 'throw' is used for group searching user includes referral role.
> It can be reproduced by using configuration from [1] with referral mode 'throw'.
> Thrown exception on trace level:
> {code}
> TRACE [org.wildfly.security] (management task-1) BASIC: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:176)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> 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)
> Caused by: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:98)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
> ... 12 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:336)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
> at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1797)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1826)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:477)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:472)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:757)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:92)
> ... 13 more
> Caused by: java.io.IOException: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:203)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
> ... 23 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:315)
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:221)
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
> ... 24 more
> {code}
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1417272#c1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2853) Referral mode 'throw' for searching groups in legacy LDAP realm causes NPE
by Jiri Ondrusek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2853?page=com.atlassian.jira.plugi... ]
Jiri Ondrusek updated WFCORE-2853:
----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2750 (was: https://github.com/wildfly/wildfly-core/pull/2749)
> Referral mode 'throw' for searching groups in legacy LDAP realm causes NPE
> --------------------------------------------------------------------------
>
> Key: WFCORE-2853
> URL: https://issues.jboss.org/browse/WFCORE-2853
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 3.0.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Jiri Ondrusek
>
> When referral mode 'throw' is configured for LDAP outbound connection which is used by legacy LDAP security realm and its groups are assigned through principal-to-group LDAP authorization then it finishes with NPE. It causes that Management Console returns status 500 when referral mode 'throw' is used for group searching user includes referral role.
> It can be reproduced by using configuration from [1] with referral mode 'throw'.
> Thrown exception on trace level:
> {code}
> TRACE [org.wildfly.security] (management task-1) BASIC: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:176)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> 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)
> Caused by: org.wildfly.security.http.HttpAuthenticationException: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:98)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:154)
> ... 12 more
> Caused by: org.wildfly.security.auth.server.RealmUnavailableException: java.io.IOException: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:336)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getAuthorizationIdentity(LdapSubjectSupplementalService.java:319)
> at org.wildfly.security.auth.realm.AggregateSecurityRealm$Identity.getAuthorizationIdentity(AggregateSecurityRealm.java:157)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(ServerAuthenticationContext.java:1797)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.authorize(ServerAuthenticationContext.java:1826)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:477)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.authorize(ServerAuthenticationContext.java:472)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:757)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authorize(UsernamePasswordAuthenticationMechanism.java:92)
> ... 13 more
> Caused by: java.io.IOException: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:203)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$SecurityRealmImpl$RealmIdentityImpl.getGroups(LdapSubjectSupplementalService.java:334)
> ... 23 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:315)
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:221)
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:225)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroupEntries(LdapSubjectSupplementalService.java:250)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:227)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:220)
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapGroupSearcher.loadGroups(LdapSubjectSupplementalService.java:194)
> ... 24 more
> {code}
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1417272#c1
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3209) KerberosHttpMgmtSaslTestCase fails on JDK9 and IBM JDK8
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3209?page=com.atlassian.jira.plugi... ]
Martin Choma edited comment on WFCORE-3209 at 8/29/17 1:15 AM:
---------------------------------------------------------------
In JBEAP-10861 it was explitely discussed Subject.doAs will not work. Does it mean with JDK9 it will works again?
was (Author: mchoma):
In JBEAP-10861 it was explitely discussed Subject.doAs will not work. Does it mean with JDK9 it will work again?
> KerberosHttpMgmtSaslTestCase fails on JDK9 and IBM JDK8
> --------------------------------------------------------
>
> Key: WFCORE-3209
> URL: https://issues.jboss.org/browse/WFCORE-3209
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.1.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Tomaz Cerar:
> kerberos tests in wildfly-core fail on jdk9 & ibm jdk 8
> {code}
> KerberosHttpMgmtSaslTestCase.testGssapiOverSsl
> KerberosHttpMgmtSaslTestCase.testGssapiWithoutSsl
> KerberosNativeMgmtSaslTestCase.testGssapiOverSsl
> KerberosNativeMgmtSaslTestCase.testGssapiWithoutSsl
> {code}
> regression was introduced as part of https://ci.wildfly.org/viewLog.html?buildId=71460&tab=buildChangesDiv&bui... changeset
> probably as part of WFCORE-3179
> Root exception is
> {code}GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt){code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
The appenders mentioned in the log4jwildfly.properties they are normal lo4j 1 appenders.
But the one that is a custom handler that is being added to the logging subsystems that is definitely just a simple JUL appender with router functionality.
I mean I completely understand that the logging subsystems is load the log4j module as you explained. In this way it can route the log4j events to the logmanager.
And in fact I tried your module configuration solution this weekend. And it does not work for one reason, when you take that module and you tell it to reconfigure itself using the property configurator it behaves as if the log4j?early.properties had an additional appender I have not configured to route to the logmanager. Therefore the log4j on wildfly base module is booby trapped to always put logevents into the logmanager and that would create infinite logging.
On the point that module subsystem is fore sure ensuring class isolation, then there is a phenomenal to be understood.
That is why does the current approach work all the time except on the first startup of wildfly?
Why is it that the normal behaviour I get is that my appender can be isolated from the subsytem loaded log4j implementation most of the time, but not on my first try to start wildfly on an arbitrary startup mode. Either via eclipse or startup bat.
I am quite certain there is a bug.
The fact that I get this mixed behaviour is one the reasons.
But there is another.
I know that it really does not matter whether or not wildfly when booting up the log susbystem will boot up log4j Jboss implementation to route to the logmanager.
Why because I know that my custom appender is banned form even manipulating the JUL LogRecord extension from wildfly that is pumped with all attional metadata such as MDC context thread name and such
If only appender I want to get access to this class I must ensure that I say that my module where my router appender extis depends on org.jbss.logmanager. otherwise I get class definition of found exception or something of the sort.
So that means by appender module is in general! Isolated from even using the jul LogRecord it is being handed over to handle
That means the default behaviour is correct. And the fact that the subsytem has loaded log4j on version A should be irrelevant for my handler because it is an isolated module that does not want to mess around with any classes from that knows module.
Soithinkthereismost definitely about here.
Many thanks for all the Input.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months