[JBoss JIRA] (AS7-5337) Vault utility outputing incorrect shared key values
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-5337:
-------------------------------------
Summary: Vault utility outputing incorrect shared key values
Key: AS7-5337
URL: https://issues.jboss.org/browse/AS7-5337
Project: Application Server 7
Issue Type: Bug
Components: Security
Environment: No affects version as this is master as on 10th August 2012 - the 7.1 branch does not show this behaviour.
Reporter: Darran Lofthouse
Assignee: Anil Saldhana
Fix For: 7.2.0.Alpha1
Adding a new vault entry results in the following (invalid) output - the shared key appears to be an object reference: -
{code}
********************************************
Vault Block:darranl
Attribute Name:password
Shared Key:[B@79de256f
Configuration should be done as follows:
VAULT::darranl::password::[B@79de256f
********************************************
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (SECURITY-680) AbstractServerLoginModule.commit() always adds the identity Principal to the CallerPrincipal group
by Tom Fonteyne (JIRA)
Tom Fonteyne created SECURITY-680:
-------------------------------------
Summary: AbstractServerLoginModule.commit() always adds the identity Principal to the CallerPrincipal group
Key: SECURITY-680
URL: https://issues.jboss.org/browse/SECURITY-680
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JBossSX
Affects Versions: PicketBox_v4_0_9.Final
Environment: JBoss EAP 6.0
Reporter: Tom Fonteyne
Assignee: Anil Saldhana
Since EAP6, AbstractServerLoginModule.commit() contains the following piece of code just before getRoleSets() is called:
// add the CallerPrincipal group
Group callerGroup = getCallerPrincipalGroup(principals);
if (callerGroup == null)
{
callerGroup = new SimpleGroup(SecurityConstants.CALLER_PRINCIPAL_GROUP);
callerGroup.addMember(identity);
principals.add(callerGroup);
}
Since getRoleSets() should also return the CallerPrincipal group (as specified in the documentation), the identity is often added to the CallerPrincipal.
As a result, the Principal used when authenticating is sometimes not the desired CallerPrincipal element but the identity (which one is determined by the backing HashMap of SimpleGroup). This can lead to security problems.
>From the Javadoc of getRoleSets():
"A second common group is "CallerPrincipal" that provides the application identity of the user rather than the security domain identity."
JBoss EAP 6 however creates this CallerPrincipal group itself with the identity SimplePrincipal as its sole member. This group is then merged with the CallerPrincipal group returned by getRoleSets(), causing the two members.
One solution could be to move the above piece of code to the end of the commit() method. This way, if getRoleSets() returns the CallerPrincipal group, this will remain unmodified, and if it does not then a new CallerPrincipal group will be created.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (LOGTOOL-51) Logging generation processing breaks APT rules by loading classes via reflection
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-51?page=com.atlassian.jira.plugin... ]
James Perkins edited comment on LOGTOOL-51 at 8/10/12 2:17 PM:
---------------------------------------------------------------
Pull request sent https://github.com/jboss-logging/jboss-logging-tools/pull/5
was (Author: jamezp):
Pull request sent https://github.com/jboss-logging/jboss-logging-tools/pull/4
> Logging generation processing breaks APT rules by loading classes via reflection
> --------------------------------------------------------------------------------
>
> Key: LOGTOOL-51
> URL: https://issues.jboss.org/browse/LOGTOOL-51
> Project: Log Tool
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: JBDS 5.5.0.CR1
> Reporter: Fred Bricon
> Assignee: David Lloyd
> Priority: Blocker
> Attachments: codemodel-2.6.jar, jboss-logging-processor-1.1.0.Beta1-SNAPSHOT.jar
>
>
> JBDS 5.5.0.CR1 embeds [m2e-apt|https://github.com/jbosstools/m2e-apt], which automatically enables Eclipse JDT Annotation Processor Toolkit.
> When importing the [server|https://github.com/jbossas/jboss-as/tree/master/server] module from http://github.com/jbossas/jboss-as.git (also happens for other modules), Eclipse starts crashing (see JBIDE-12087) with errors like :
> {noformat}
> javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory not found
> at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:127)
> at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.decodeFactoryPath(FactoryPathUtil.java:222)
> at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.readFactoryPathFile(FactoryPathUtil.java:115)
> at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.calculatePath(FactoryPathUtil.java:342)
> at org.eclipse.jdt.apt.core.internal.util.FactoryPathUtil.getFactoryPath(FactoryPathUtil.java:429)
> at org.eclipse.jdt.apt.core.internal.AnnotationProcessorFactoryLoader.getJava6FactoriesAndAttributesForProject(AnnotationProcessorFactoryLoader.java:420)
> at org.eclipse.jdt.internal.apt.pluggable.core.dispatch.IdeAnnotationProcessorManager.processAnnotations(IdeAnnotationProcessorManager.java:130)
> at org.eclipse.jdt.internal.compiler.Compiler.processAnnotations(Compiler.java:813)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:432)
> at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:364)
> at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:178)
> at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:301)
> at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60)
> at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
> at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: java.lang.ClassNotFoundException: __redirected/__DocumentBuilderFactory
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:119)
> at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:144)
> at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:185)
> at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:121)
> {noformat}
> It turns out the Eclipse System Properties have been changed to use javax.xml.parsers.SAXParserFactory=__redirected/__DocumentBuilderFactory
> I tracked the code responsible with messing with the properties :
> {noformat}
> Thread [Worker-24] (Suspended (breakpoint at line 779 in System))
> System.setProperty(String, String) line: 779
> __SAXParserFactory.<clinit>() line: 68
> __JAXPRedirected.initAll() line: 80
> Module$1.run() line: 126
> Module$1.run() line: 113
> AccessController.doPrivileged(PrivilegedAction<T>) line: not available [native method]
> Module.<clinit>() line: 113
> Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method]
> Class<T>.forName(String) line: 186 <====== org.jboss.modules.Module
> JCodeModel.ref(String) line: 363
> MessageBundleImplementor(ImplementationClassModel).createBundleMethod(MessageMethod, JMethod, JMethod, JVar) line: 150
> MessageBundleImplementor.generateModel() line: 86
> MessageBundleImplementor(ClassModel).create(JavaFileObject) line: 104
> ImplementationClassGenerator.processTypeElement(TypeElement, TypeElement, MessageInterface) line: 63
> LoggingToolsProcessor.process(Set<TypeElement>, RoundEnvironment) line: 155
> RoundDispatcher.handleProcessor(ProcessorInfo) line: 139
> RoundDispatcher.round() line: 121
> IdeAnnotationProcessorManager(BaseAnnotationProcessorManager).processAnnotations(CompilationUnitDeclaration[], ReferenceBinding[], boolean) line: 159
> IdeAnnotationProcessorManager.processAnnotations(CompilationUnitDeclaration[], ReferenceBinding[], boolean) line: 134
> Compiler.processAnnotations() line: 813
> Compiler.compile(ICompilationUnit[]) line: 432
> BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[], SourceFile[], boolean) line: 364
> BatchImageBuilder.compile(SourceFile[], SourceFile[], boolean) line: 178
> BatchImageBuilder(AbstractImageBuilder).compile(SourceFile[]) line: 301
> BatchImageBuilder.build() line: 60
> JavaBuilder.buildAll() line: 254
> JavaBuilder.build(int, Map, IProgressMonitor) line: 173
> BuildManager$2.run() line: 728
> SafeRunner.run(ISafeRunnable) line: 42
> BuildManager.basicBuild(int, IncrementalProjectBuilder, Map<String,String>, MultiStatus, IProgressMonitor) line: 199
> BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, ICommand[], MultiStatus, IProgressMonitor) line: 239
> BuildManager$1.run() line: 292
> SafeRunner.run(ISafeRunnable) line: 42
> BuildManager.basicBuild(IBuildConfiguration, int, IBuildContext, MultiStatus, IProgressMonitor) line: 295
> BuildManager.basicBuildLoop(IBuildConfiguration[], IBuildConfiguration[], int, MultiStatus, IProgressMonitor) line: 351
> BuildManager.build(IBuildConfiguration[], IBuildConfiguration[], int, IProgressMonitor) line: 374
> AutoBuildJob.doBuild(IProgressMonitor) line: 143
> AutoBuildJob.run(IProgressMonitor) line: 241
> Worker.run() line: 54
> {noformat}
> That stacktrace represents the processing of https://github.com/jbossas/jboss-as/blob/master/server/src/main/java/org/...
> So basically, whenever a Logger has a dependency to the [org.jboss.modules.Module|https://github.com/jbossas/jboss-modules/blob/ma...] class, stuff starts hitting the fan.
> Classes should not be loaded by reflection during APT processing to avoid such issues - it should use the API provided by APT to iterate over the classes metadata provided by the compiler and not depend on com.sun.*.internal classes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5330) HornetQSecurityManagerAS7 is not restoring the original security context when it pops its own
by Ed Roberts (JIRA)
Ed Roberts created AS7-5330:
-------------------------------
Summary: HornetQSecurityManagerAS7 is not restoring the original security context when it pops its own
Key: AS7-5330
URL: https://issues.jboss.org/browse/AS7-5330
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.1.Final
Environment: Windows XP SP2
JDK 1.6.0_32
Eclipse Indigo for JMS Client invocation
Reporter: Ed Roberts
Assignee: Andy Taylor
I have added the HornetQ acceptor, connector and connection factory to allow JMS over HTTP tunneling.
I tested a message send using an external JMS Client.
The following exception is thrown during the transmission
2012-08-09 10:50:07,155 ERROR [org.apache.catalina.connector.CoyoteAdapter](http-executor-threads - 1) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: JBAS018053: No security context found
at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:136)
at org.jboss.as.web.security.SecurityActions$6.run(SecurityActions.java:130)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.as.web.security.SecurityActions.popRunAsIdentity(SecurityActions.java:130)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:155)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:518)
at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:842)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
After some debugging, I can make out that this has exposed a fault in the HornetQSecurityManagerAS7. When it is active, it pushes the "other" security context from my configuration into the active security context, but when done and pops its security context, it does not restore the original, which was the jboss-web-policy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5339) JBoss 7.2-alpha.zip
by Rodney Kite (JIRA)
Rodney Kite created AS7-5339:
--------------------------------
Summary: JBoss 7.2-alpha.zip
Key: AS7-5339
URL: https://issues.jboss.org/browse/AS7-5339
Project: Application Server 7
Issue Type: Bug
Components: Class Loading
Affects Versions: 7.2.0.Alpha1
Environment: Windows 7 64 bit, Oracle Jdk 1.6.0 32 bit
Reporter: Rodney Kite
Assignee: David Lloyd
During deployment there is an ERROR.
Failed to start service jboss.module.service."deployment.Mef.ear".main JBAS018759: Failed to load module: deployment.Mef.ear:main ...
Caused by: org.jboss.modules.ModuleNotFoundException: deployment.MefBusiness.ear.mefCommon.jar:main
A deployment ear has a jar that references another deployment ears jar/module indicated in the referencing jars "Dependencies:" secion of its Manifest.MF. It seems that dynamic deployment modules are not visible to other ears referencing them.
This works fine in JBoss 7.1.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (AS7-1370) Domain Management - Add support for database authentication.
by Darran Lofthouse (JIRA)
Domain Management - Add support for database authentication.
------------------------------------------------------------
Key: AS7-1370
URL: https://issues.jboss.org/browse/AS7-1370
Project: Application Server 7
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.1.0.Beta1
It should be possible to define a database authentication element for authentication of incoming connections against a database.
Ideally the password should be obtainable from the database to allow us to use DIGEST authentication but if not a fallback to verify the password should be supported.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-3570) jboss-ejb3.xml is not valided
by Simon Walter (JIRA)
Simon Walter created AS7-3570:
---------------------------------
Summary: jboss-ejb3.xml is not valided
Key: AS7-3570
URL: https://issues.jboss.org/browse/AS7-3570
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.0.CR1b
Reporter: Simon Walter
Priority: Minor
When deploying a module with invalid jboss-ejb3.xml (missing <ejb-name> in <assembly-descriptor><security:security>) there
is no validation and an NPE is thrown at deployment time.
{noformat}
11:02:45,347 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service
jboss.deployment.subunit."xxx.ear"."xxx-impl.jar".POST_MODULE: org.jboss.msc.service.StartException in service
jboss.deployment.subunit."xxx.ear"."xxx-impl.jar".POST_MODULE: Failed to process phase POST_MODULE of subdeployment "xxx-impl.jar"
of deployment "xxx.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS014402: Could not merge data for XXXImpl
at org.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:75)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.CR1b.jar:7.1.0.CR1b]
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.deployment.processors.merging.SecurityDomainMergingProcessor.handleDeploymentDescriptor(SecurityDomainMergingProcessor.java:83)
at org.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.processComponentConfig(AbstractMergingProcessor.java:93)
at org.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:73)
... 6 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months