[JBoss JIRA] (SECURITY-877) AdvancedLdapLodinMogule is Logging LDAP Bind Credential Password during authentication.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-877?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-877:
--------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1199641|https://bugzilla.redhat.com/show_bug.cgi?id=1199641] from VERIFIED to CLOSED
> AdvancedLdapLodinMogule is Logging LDAP Bind Credential Password during authentication.
> ---------------------------------------------------------------------------------------
>
> Key: SECURITY-877
> URL: https://issues.jboss.org/browse/SECURITY-877
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_2_3_6_Final
> Environment: Wildfly is logging the bindCredentials when using SPNEGO
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Fix For: Negotiation_2_3_7_Final
>
>
> The bind Credential are being logged:
> 2015-03-19 19:33:28,569 TRACE [org.jboss.security.auth.spi.AbstractServerLoginModule] (http-localhost/127.0.0.1:8080-1) Logging into LDAP server, env={baseFilter=(userPrincipalName={0}), java.naming.security.credentials=***, jboss.security.security_domain=SPNEGO, java.naming.ldap.attributes.binary=objectSid, password-stacking=useFirstPass, recurseRoles=false, java.naming.security.authentication=simple, baseCtxDN=DC=example,DC=com, roleAttributeIsDN=true, rolesCtxDN=DC=example,DC=com, java.naming.security.principal=bindUser, allowEmptyPassword=true, java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://127.0.0.1:389, roleNameAttributeID=cn, roleAttributeID=memberOf, bindDN=bindUser, bindCredential=password}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-227:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1193926|https://bugzilla.redhat.com/show_bug.cgi?id=1193926] from VERIFIED to CLOSED
> RejectedExecutionException when closing ModelControllerClient client
> --------------------------------------------------------------------
>
> Key: WFCORE-227
> URL: https://issues.jboss.org/browse/WFCORE-227
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Affects Versions: 1.0.0.Alpha11
> Reporter: Alessio Soldano
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha15
>
>
> After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite:
> {noformat}
> Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3@5651c0c2 rejected from org.xnio.XnioWorker$TaskPool@11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4]
> at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048)
> at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372)
> at org.xnio.XnioWorker.execute(XnioWorker.java:741)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363)
> at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method.
> The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-639) ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-639?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-639:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1230394|https://bugzilla.redhat.com/show_bug.cgi?id=1230394] from VERIFIED to CLOSED
> ManagementPermissionAuthorizer is limited to the standard roles for its authorizeJmxOperation impl
> --------------------------------------------------------------------------------------------------
>
> Key: WFCORE-639
> URL: https://issues.jboss.org/browse/WFCORE-639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Fix For: 2.0.0.Alpha3
>
>
> ManagementPermissionAuthorizer.authorizeJmxOperation uses hard coded decision making based on the standard 7 roles. This is inflexible and specifically doesn't allow scoped roles to function properly.
> I believe the JmxPermissionFactory interface needs to be redone to use permissions instead of role names. It should have an API more like org.jboss.as.controller.access.permission.PermissionFactory, with getUserPermissions and getRequiredPermissions. Something like
> PermissionCollection getUserPermissions(Caller caller, Environment callEnvironment, JmxAction action)
> PermissionCollection getRequiredPermissions(JmxAction action);
> Then ManagementPermissionAuthorizer.authorizeJmxOperation does a permission match check similar to what it does for management resource permissions.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-608) Using ? as control character in .inputrc causes CLI to terminate immediately.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-608?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-608:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1203997|https://bugzilla.redhat.com/show_bug.cgi?id=1203997] from VERIFIED to CLOSED
> Using ? as control character in .inputrc causes CLI to terminate immediately.
> ------------------------------------------------------------------------------
>
> Key: WFCORE-608
> URL: https://issues.jboss.org/browse/WFCORE-608
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: Linux
> Reporter: Jay SenSharma
> Assignee: Alexey Loubyansky
> Fix For: 1.0.0.CR4, 2.0.0.Alpha1
>
>
> - When using *[wildfly-8.2.0.Final]* When user has a '.inputrc' in the user home directory with the following content:
> {code}
> # Control characters
> "\C-?": backward-delete-char
> {code}
> - The it fails with the the following Stack Trace:
> {code}
> ./jboss-cli.sh
> java.lang.RuntimeException: ERROR parsing ? keys to aesh. Check your inputrc.
> at org.jboss.aesh.edit.mapper.KeyMapper.convertRandomControlKeys(KeyMapper.java:161)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapRandomKeys(KeyMapper.java:138)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapKeys(KeyMapper.java:108)
> at org.jboss.aesh.edit.mapper.KeyMapper.mapQuoteKeys(KeyMapper.java:49)
> at org.jboss.aesh.console.Config.parseInputrc(Config.java:127)
> at org.jboss.aesh.console.Console.reset(Console.java:150)
> at org.jboss.aesh.console.Console.<init>(Console.java:105)
> at org.jboss.aesh.console.Console.<init>(Console.java:101)
> at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85)
> at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78)
> at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349)
> at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296)
> at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:312)
> at org.jboss.modules.Main.main(Main.java:460)
> {code}
> - Expectation is that CLI should not have terminated suddenly rather the exception should have been handled in a proper way.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-505) Fix double redeployment due to .failed file and a artifact with newer timestamp.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-505?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-505:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1169239|https://bugzilla.redhat.com/show_bug.cgi?id=1169239] from VERIFIED to CLOSED
> Fix double redeployment due to .failed file and a artifact with newer timestamp.
> --------------------------------------------------------------------------------
>
> Key: WFCORE-505
> URL: https://issues.jboss.org/browse/WFCORE-505
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0.0.Alpha15
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 1.0.0.Beta5
>
>
> Issue found and described in https://bugzilla.redhat.com/show_bug.cgi?id=1169239
> steps to reproduce:
> 1. deploy a "Test.war"
> 2. Change something in "Test.war" to fail it.
> 3. "Test.war.failed" file will be created.
> 4. stop JBoss EAP.
> 5. Revert the changes done in "Test.war" so that it will deploy successfully.
> 6. Now there are two files ("Test.war.failed" and "Test.war", due to correction, Test.war must have a newer timestamp than Test.war.failed)in deployment directory.
> 7. Restart JBoss EAP, it will fail with below Error :
> The problem happens as a result of redundant redeployment in next reboot. During servert reboot, it will try to redeploy the application due to found .failed file, it also will try to redeploy same application because Test.war has a newer timestamp to see the problem. This will cause server startup failure as:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) JBAS014613: Operation ("add") failed - address: ([("deployment" => "Test.war")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"Test.war\")]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-553) ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-553?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-553:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1199319|https://bugzilla.redhat.com/show_bug.cgi?id=1199319] from VERIFIED to CLOSED
> ModelControllerClientOperationHandler doesn't manage the clientRequestExecutor properly
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-553
> URL: https://issues.jboss.org/browse/WFCORE-553
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha18
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Beta1
>
>
> ModelControllerClientOperationHandler's constructor creates a ThreadPoolExecutor for handling client requests and then the class doesn't clean it up.
> In addition, an instance of ModelControllerClientOperationHandler is created per channel, not one per ModelControllerClientOperationHandlerFactoryService. I know I at least thought of the thread pool as being per remote management interface, not per channel.
> Making it be per ModelControllerClientOperationHandlerFactoryService and cleaning it up in that service's stop would be the easiest fix, but the pool settings may not be appropriate if we do that, so tread carefully.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4331:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1188420|https://bugzilla.redhat.com/show_bug.cgi?id=1188420] from VERIFIED to CLOSED
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months