[JBoss JIRA] (WFLY-6411) Deploying and undeploying default web application with welcome root results in 404 (instead of returning content defined by welcome-content handler)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-6411?page=com.atlassian.jira.plugin.... ]
Tomas Hofman moved JBEAP-3908 to WFLY-6411:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6411 (was: JBEAP-3908)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> Deploying and undeploying default web application with welcome root results in 404 (instead of returning content defined by welcome-content handler)
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6411
> URL: https://issues.jboss.org/browse/WFLY-6411
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Optional
>
> * When I install EAP and access http://localhost:8080/ welcome page is returned. - OK
> * When I deploy my custom web application with the app defined for root context => in jboss-web.xml there is defined {{<context-root>/</context-root>}}, after accessing http://localhost:8080/ the content of my application is returned. - OK
> * When I undeploy the previously custom application used as default welcome page and try to access http://localhost:8080/, the 404 is returned (I would expect 200 is returned with the original welcome page defined by the welcome-file handler.
> Note: Reloading the server configuration makes the original welcome page again accessible.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-778) Only one deployed application can use custom mailcap
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-778?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar updated WFLY-778:
-----------------------------
Component/s: Mail
> Only one deployed application can use custom mailcap
> ----------------------------------------------------
>
> Key: WFLY-778
> URL: https://issues.jboss.org/browse/WFLY-778
> Project: WildFly
> Issue Type: Bug
> Components: EE, Mail
> Environment: AS 7, many applications deployed with custom mailcaps.
> Reporter: Philippe Guinot
> Assignee: Tomaz Cerar
> Priority: Minor
> Labels: activation, javax, mail, mailcap, mailcapcommandmap
>
> In the MailcapCommandMap class, it loads the mailcap file only once. This may cause troubles when different applications use different custom mailcap.
> Also, if no mailcap is found in the current class loader, only ONE mailcap file from the module will be loaded, and not all of them, which is an issue if we get the mail-dsn jar added in the javax.mail.api module.
> If there is only one application deployed, adding in the jboss-deployement-structure.xml the following dependency:
> {code:xml}<module name="javax.mail.api"><imports><include path="META-INF"/><include path="META-INF/**"/></imports></module>{code}
> and, from the application, calling at startup:
> {code}javax.activation.CommandMap.setDefaultCommandMap(new MailcapCommandMap());{code}
> cause the loading of all mailcap files found from the current class loader (those of the application + those of javax.mail.api module).
> But, if there are more than one application deployed, only the first to do so will have its mailcap loaded.
> The design of javax.activation should be changed to take in account this side-effect of isolation: what happen if 2 applications define different classes for the same type/mime ??
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (JGRP-2033) Replace Java serialization with JGroups marshalling
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2033?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2033:
---------------------------
Description: In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}). Analysis of all occurrences of {{Util.objectFromXXX()}} calls. (was: In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}).)
> Replace Java serialization with JGroups marshalling
> ---------------------------------------------------
>
> Key: JGRP-2033
> URL: https://issues.jboss.org/browse/JGRP-2033
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.9, 4.0
>
>
> In some cases, even JGroups internal code still uses Java serialization. Replace this with marshalling (using {{Streamable}}). Analysis of all occurrences of {{Util.objectFromXXX()}} calls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-4886) jboss-permissions.xml in EAR module allows to grant additional permissions
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-4886?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-4886.
-------------------------------
Resolution: Rejected
I am rejecting this issue. The reason is manifold:
* Accepting JBoss-specific descriptors which override standard ones is done in many many places, without the necessity to add a switch to disable it. This in no way compromises our compliance with Java EE.
* The same deployer role which can assign, remove, or modify permissions.xml files may also do the same for jboss-permissions.xml. There is no reason to assume that such a role would not have the ability to do so, thereby allowing some nefarious developer to gain illicit permissions, which is the justification basis of this issue.
* Any permissions which are definitely undesired can be restricted globally in the server configuration.
> jboss-permissions.xml in EAR module allows to grant additional permissions
> --------------------------------------------------------------------------
>
> Key: WFLY-4886
> URL: https://issues.jboss.org/browse/WFLY-4886
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 10.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Introduce a switch in WildFly configuration, which will enable "strict handling of permissions.xml", i.e. it'll allow administrator to disable parsing {{jboss-permissions.xml}} in submodules.
> If the file {{META-INF/jboss-permissions.xml}} is present in a module of EAR application, then the permissions from the {{jboss-permissions.xml}} are granted to the module. The EE specification doesn't allow this.
> From my PoV it is a security issue, because the application deployer - based on EE specification - is only configuring {{META-INF/permissions.xml}}. I.e the deployer is granting a limited set of permissions for the application. If the {{jboss-permissions.xml}} in a module grants more permissions then the limit requested by the deployer is not used and the module is granted to do anything.
> More details:
> - Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=342]) in section EE.6.2.2.6 says:
> _For applications packaged in an .ear file, the declaration of permissions *must* be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules._
> - David says in [a comment|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] of WFLY-400:
> _We should additionally support a jboss-permissions.xml descriptor with the same schema/syntax. If such a file is present in a top-level deployment, it should take precedence over permissions.xml; if present in a subdeployment, it should replace the permissions for that subdeployment's code source (and any other nested JARs contained therein) only._
> - Stefan says in [PermissionsParseProcessor|https://github.com/wildfly/wildfly/blob/9.0.0.F...] JavaDoc:
> _As can be noted, the EE spec doesn't allow sub-deployments to override permissions set at the .ear level. We find it a bit too restrictive, so we introduced the META-INF/jboss-permissions.xml descriptor. It uses the same schema as the standard permissions.xml file but, unlike the latter, is always processed and the permissions contained in it override any permissions set by a parent deployment. If a deployment contains both permissions files, jboss-permissions.xml takes precedence over the standard permissions.xml._
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1101) Upgrade protobuf-java from 2.5.0 to 2.6.0
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created DROOLS-1101:
----------------------------------------
Summary: Upgrade protobuf-java from 2.5.0 to 2.6.0
Key: DROOLS-1101
URL: https://issues.jboss.org/browse/DROOLS-1101
Project: Drools
Issue Type: Task
Components: core engine
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
>From RPM discussion (BPMSPL-282)
Productization: protobuf-java redhat version is: 2.6.0-redhat-1, is it ok to upgrade from 2.5.0->2.6.0?
Motivation:
- The 2.5 version isn't build from source by productization, there is no redhat version.
- The 2.6 version is, which means they can do security patches on it easily (= important for long term support) and it can be RPM'ed (important for BPMSPL-282, which has PM support)
- 2.6 is higher than 2.5, so in theory this is low-risk change.
Needed on both master and 6.4.x.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6319) NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
by Dmitrii Tikhomirov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6319?page=com.atlassian.jira.plugin.... ]
Dmitrii Tikhomirov commented on WFLY-6319:
------------------------------------------
Cool, let me check that
> NPE in LocalEjbReceiver.removeClusterNodes during server shutdown
> -----------------------------------------------------------------
>
> Key: WFLY-6319
> URL: https://issues.jboss.org/browse/WFLY-6319
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Reporter: Ladislav Thon
> Assignee: Dmitrii Tikhomirov
>
> In a failover test that passivates sessions to a SQL database (though I think this isn't really relevant much), I've seen a NPE in {{LocalEjbReceiver.removeClusterNodes}}:
> {code}
> 04:09:29,330 WARN [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000004: Failure during stop of service jboss.ejb3.localEjbReceiver.value: java.lang.NullPointerException
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.removeClusterNodes(LocalEjbReceiver.java:701)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.disassociate(LocalEjbReceiver.java:681)
> at org.jboss.ejb.client.EJBClientContext.unregisterEJBReceiver(EJBClientContext.java:446)
> at org.jboss.ejb.client.EJBReceiverContext.close(EJBReceiverContext.java:57)
> at org.jboss.as.ejb3.remote.LocalEjbReceiver.stop(LocalEjbReceiver.java:410)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 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)
> {code}
> This happens during server shutdown, so it probably doesn't affect anything.
> Logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-db-s...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-4886) jboss-permissions.xml in EAR module allows to grant additional permissions
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-4886?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-4886:
------------------------------
Description:
Introduce a switch in WildFly configuration, which will enable "strict handling of permissions.xml", i.e. it'll allow administrator to disable parsing {{jboss-permissions.xml}} in submodules.
If the file {{META-INF/jboss-permissions.xml}} is present in a module of EAR application, then the permissions from the {{jboss-permissions.xml}} are granted to the module. The EE specification doesn't allow this.
>From my PoV it is a security issue, because the application deployer - based on EE specification - is only configuring {{META-INF/permissions.xml}}. I.e the deployer is granting a limited set of permissions for the application. If the {{jboss-permissions.xml}} in a module grants more permissions then the limit requested by the deployer is not used and the module is granted to do anything.
More details:
- Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=342]) in section EE.6.2.2.6 says:
_For applications packaged in an .ear file, the declaration of permissions *must* be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules._
- David says in [a comment|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] of WFLY-400:
_We should additionally support a jboss-permissions.xml descriptor with the same schema/syntax. If such a file is present in a top-level deployment, it should take precedence over permissions.xml; if present in a subdeployment, it should replace the permissions for that subdeployment's code source (and any other nested JARs contained therein) only._
- Stefan says in [PermissionsParseProcessor|https://github.com/wildfly/wildfly/blob/9.0.0.F...] JavaDoc:
_As can be noted, the EE spec doesn't allow sub-deployments to override permissions set at the .ear level. We find it a bit too restrictive, so we introduced the META-INF/jboss-permissions.xml descriptor. It uses the same schema as the standard permissions.xml file but, unlike the latter, is always processed and the permissions contained in it override any permissions set by a parent deployment. If a deployment contains both permissions files, jboss-permissions.xml takes precedence over the standard permissions.xml._
was:
If the file {{META-INF/jboss-permissions.xml}} is present in a module of EAR application, then the permissions from the {{jboss-permissions.xml}} are granted to the module. The EE specification doesn't allow this.
>From my PoV it is a security issue, because the application deployer - based on EE specification - is only configuring {{META-INF/permissions.xml}}. I.e the deployer is granting a limited set of permissions for the application. If the {{jboss-permissions.xml}} in a module grants more permissions then the limit requested by the deployer is not used and the module is granted to do anything.
More details:
- Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=342]) in section EE.6.2.2.6 says:
_For applications packaged in an .ear file, the declaration of permissions *must* be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules._
- David says in [a comment|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] of WFLY-400:
_We should additionally support a jboss-permissions.xml descriptor with the same schema/syntax. If such a file is present in a top-level deployment, it should take precedence over permissions.xml; if present in a subdeployment, it should replace the permissions for that subdeployment's code source (and any other nested JARs contained therein) only._
- Stefan says in [PermissionsParseProcessor|https://github.com/wildfly/wildfly/blob/9.0.0.F...] JavaDoc:
_As can be noted, the EE spec doesn't allow sub-deployments to override permissions set at the .ear level. We find it a bit too restrictive, so we introduced the META-INF/jboss-permissions.xml descriptor. It uses the same schema as the standard permissions.xml file but, unlike the latter, is always processed and the permissions contained in it override any permissions set by a parent deployment. If a deployment contains both permissions files, jboss-permissions.xml takes precedence over the standard permissions.xml._
> jboss-permissions.xml in EAR module allows to grant additional permissions
> --------------------------------------------------------------------------
>
> Key: WFLY-4886
> URL: https://issues.jboss.org/browse/WFLY-4886
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager
> Affects Versions: 10.0.0.Alpha4
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Introduce a switch in WildFly configuration, which will enable "strict handling of permissions.xml", i.e. it'll allow administrator to disable parsing {{jboss-permissions.xml}} in submodules.
> If the file {{META-INF/jboss-permissions.xml}} is present in a module of EAR application, then the permissions from the {{jboss-permissions.xml}} are granted to the module. The EE specification doesn't allow this.
> From my PoV it is a security issue, because the application deployer - based on EE specification - is only configuring {{META-INF/permissions.xml}}. I.e the deployer is granting a limited set of permissions for the application. If the {{jboss-permissions.xml}} in a module grants more permissions then the limit requested by the deployer is not used and the module is granted to do anything.
> More details:
> - Java EE 7 spec ([JSR 342|https://www.jcp.org/en/jsr/detail?id=342]) in section EE.6.2.2.6 says:
> _For applications packaged in an .ear file, the declaration of permissions *must* be at .ear file level. This permission set is applied to all modules and libraries packaged within the .ear file or within its contained modules._
> - David says in [a comment|https://issues.jboss.org/browse/WFLY-400?focusedCommentId=1276158...] of WFLY-400:
> _We should additionally support a jboss-permissions.xml descriptor with the same schema/syntax. If such a file is present in a top-level deployment, it should take precedence over permissions.xml; if present in a subdeployment, it should replace the permissions for that subdeployment's code source (and any other nested JARs contained therein) only._
> - Stefan says in [PermissionsParseProcessor|https://github.com/wildfly/wildfly/blob/9.0.0.F...] JavaDoc:
> _As can be noted, the EE spec doesn't allow sub-deployments to override permissions set at the .ear level. We find it a bit too restrictive, so we introduced the META-INF/jboss-permissions.xml descriptor. It uses the same schema as the standard permissions.xml file but, unlike the latter, is always processed and the permissions contained in it override any permissions set by a parent deployment. If a deployment contains both permissions files, jboss-permissions.xml takes precedence over the standard permissions.xml._
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month