[JBoss JIRA] (WFLY-490) Domain Management Role Based Access Control
by Gopi Chand Uppala (JIRA)
[ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.s... ]
Gopi Chand Uppala commented on WFLY-490:
----------------------------------------
Brian, I thought this would be roled into EAP 6.2. Could you please confirm when this will be available?
> Domain Management Role Based Access Control
> -------------------------------------------
>
> Key: WFLY-490
> URL: https://issues.jboss.org/browse/WFLY-490
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: Authorization
> Fix For: 8.0.0.Final
>
>
> Implement some coarse permissions for domain operations. Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute.
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-2681) HTTP Management Interface Content-Type header is broken
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2681?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-2681:
------------------------------------
Assignee: Stuart Douglas (was: Brian Stansberry)
> HTTP Management Interface Content-Type header is broken
> -------------------------------------------------------
>
> Key: WFLY-2681
> URL: https://issues.jboss.org/browse/WFLY-2681
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.CR1
> Reporter: Dino Tsoumakis
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Final
>
>
> *Problem:*
> HTTP Domain Management Interfaces returns invalid Content-Type header:
> {code}
> Content-Type: application/json;utf-8
> {code}
> This breaks management for lots of REST clients.
> *Proposed solution:*
> According to [W3C|https://www.w3.org/International/O-HTTP-charset] and [rfc2616|http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7] the Content-Type header should be:
> {code}
> Content-Type: application/json; charset=utf-8
> {code}
> BTW: JBoss 7.1.1 behaviour is ok. It does not send any charset parameter at all.
> *Example:*
> Request contains the following headers:
> {code}
> 3 > Accept: application/json
> 3 > Content-Type: application/json
> ...
> {code}
> Wildfly 8.0.0.CR1 response after digest authentication is:
> {code}
> 4 < 200
> 4 < Authentication-Info: nextnonce="EB9WbpMrUuwNMTM4NzY3MDc2NzAxMgXaHXwaKEWPxbxUj1ihuOg="
> 4 < Connection: keep-alive
> 4 < Content-Type: application/json;utf-8
> 4 < Transfer-Encoding: chunked
> {code}
> JBoss 7.1.1 response after digest authentication is:
> {code}
> 4 < 200
> 4 < Content-type: application/json
> 4 < Date: Sat, 21 Dec 2013 23:48:36 GMT
> 4 < Transfer-encoding: chunked
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-131) Seam2Processor will not have permissions to its added resource loader
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-131?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved WFLY-131.
------------------------------
Fix Version/s: (was: 8.0.0.Final)
Resolution: Done
New seam-int version was merged some time ago into WildFly codebase.
> Seam2Processor will not have permissions to its added resource loader
> ---------------------------------------------------------------------
>
> Key: WFLY-131
> URL: https://issues.jboss.org/browse/WFLY-131
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: David Lloyd
> Assignee: Ales Justin
> Labels: security
> Fix For: 8.0.0.CR1
>
>
> The {{Seam2Processor}} class adds a {{VFSResourceLoader}} to the deployment in order to copy certain Seam classes into it. The problem is that the {{VFSResourceLoader}} will fail at runtime with a permission exception because there is no corresponding {{VirtualFilePermission}}.
> For this type of resource loader, it is better just to add the JAR using {{JarFileResourceLoader}}, which does not require permissions at load time and is much faster anyway.
> If you must use {{VFSResourceLoader}}, then instead of creating and adding the resource loader yourself, add a {{ResourceRoot}} to the deployment context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (WFLY-2496) Concurrent access to ModuleSpecification causes race condition
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2496?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger updated WFLY-2496:
----------------------------------
Priority: Blocker (was: Critical)
> Concurrent access to ModuleSpecification causes race condition
> --------------------------------------------------------------
>
> Key: WFLY-2496
> URL: https://issues.jboss.org/browse/WFLY-2496
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Beta1
> Reporter: Jozef Hartinger
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server...] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment.
> Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav...
> Here's how I think this problem manifests:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> {noformat}
> and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access:
> {noformat}
> "MSC service thread 1-6":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> 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:744)
> "MSC service thread 1-3":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> 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:744)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (JGRP-1762) Util.loadClass(): do we use the correct ClassLoader ?
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1762?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1762.
----------------------------
Resolution: Done
Changed the order: trying the defining classloader first, then the TCCL.
> Util.loadClass(): do we use the correct ClassLoader ?
> -----------------------------------------------------
>
> Key: JGRP-1762
> URL: https://issues.jboss.org/browse/JGRP-1762
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.2, 3.5
>
>
> Investigate whether the code below uses the right classloader. Perhaps we should try to get the classloader of the instances passed to us *before* attempting to use the calling thread's class loader ?
> The current code is:
> {noformat}
> public static Class loadClass(String classname, Class clazz) throws ClassNotFoundException {
> ClassLoader loader;
> try {
> loader=Thread.currentThread().getContextClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> if(clazz != null) {
> try {
> loader=clazz.getClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> }
> try {
> loader=ClassLoader.getSystemClassLoader();
> if(loader != null) {
> return loader.loadClass(classname);
> }
> }
> catch(Throwable t) {
> }
> throw new ClassNotFoundException(classname);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months