On 8/22/13 8:30 AM, Raymond Auge wrote:
> Thank you Ron for your response.
>
> Allow me to clarify further. And please if this is still not enough,
> just ask.
>
>
> The JSP RI (which is the forked Jasper implementation) contains the
> following:
>
> public static final boolean IS_SECURITY_ENABLED =
> (System.getSecurityManager() != null);
>
> While this seems to be innocuous enough what it really means is that
> no consumer of that impl can rely on the SecurityManager API.
>
> My first reaction was to file a bug report:
> https://java.net/jira/browse/JSP-37
>
> I also went to the original developers, the tomcat project developer
> list, and asked for their position on the matter. The discussion was
> quickly curtailed as "we don't support dynamic changes of the
> SecurityManager". Understandable, since at this point tomcat's Jasper
> is a "custom implementation" of the JSP spec.
Raymond,
I checked out your "Constants.IS_SECURITY_ENABLED", thread on the tomcat
developers list.
the EE 7 spec only requires that every product support running with a
security manager; it does not require that it be possible to dynamically
change this characteristic (presumably after the product has completed
its initialization). Also EE makes no requirement that a security
manager (or its effect, i.e., permission checking) be enabled for some
apps, while not for others. The security manager is a container
feature, intended to
protect the container and os resources that the container process may
have access to from code (typically applications) running within the
container. There should be no expectation that applications that perform
internal permission checks will be able to enable the SecurityManager of
their hosting container. Moreover the security manager and permission
requirements of EE 7 cannot be presumed to be satisfied by Non EE 7
compatible web containers (of which I think Tomcat would be an example).
iow, and imo, Tomcat's support for running with a SecurityManager
exists independent of the EE 7
requirement to be able to do so, and Tomcat's internal reliance on its
IS_SECURITY_ENABLED flag is a
Tomcat implementation detail.
that said, if an application depends on being able to perform
SecurityManager based permission checks, it will require a hosting
container in which the SecurityManager is enabled, and then I agree that
the hosting
hosting container should not interfere with the application's ability to
perform SecurityManager based permission checks according to the
recommended use pattern.
SecurityManager s = System.getSecurityManager();
(if (s != null) {
s.checkPermission(p);
}
Also, If the application learns that the security manager is not
enabled, it should not expect to be able to set a security manager for
the container. It might choose to initialize itself with reduced
functionality or to fail in its initialization. imv, the value of
IS_SECURITY_ENABLED must be consistent with that of
(System.getSeucirtyManager() != null) since the constant can have no
effect on embedded permission checks in jvm provided classes like
sockets and files...so it is likely that your app can also rely on this
consistency.
fwiw, if your app needs to perform permission checks in an environment
where you cannot rely on the security manager being enabled, then you
might want to consider making your checks by calling some other access
control api. Java also provides Policy.implies, or
AccessController.checkPermission.
HTH,
Ron
> Therefore, I had hoped that at the Java EE specification level someone
> may at least be inclined to offer a statement toward whether there is
> even grounds for making such a bug report.
>
> So my goal here is simply to identify whether there is some precedent,
> charter of behaviour, set of rules, code of conduct, etc., by which
> the Java EE specifications and their RIs are obliged to NOT break the
> behaviours of the Java SE APIs upon which they are founded, even while
> not containing or omitting specifics in their language or wording.
>
> It seems to me that the RIs developed within Java EE should not take
> liberties that custom implementations may afford to take since RIs
> tend to be, by their nature, more portable and representative of best
> practices.
>
> I hope that clarifies things.
>
> Sincerely,
> - Ray
>
>
> On Wed, Aug 21, 2013 at 12:45 PM, Ron Monzillo
> <ron.monzillo_at_oracle.com <mailto:ron.monzillo_at_oracle.com>> wrote:
>
> On 8/21/13 11:31 AM, Raymond Auge wrote:
>> Hello everyone,
>>
>> My name is Raymond Auge and this is my first email to the list.
>> Hopefully I follow proper protocol. Please let me know if I have not.
>>
>> -----
>> Sorry, my question may seem odd.
>>
>> I would like to get an official position statement on the
>> handling of the SecurityManager/Policy APIs with respect to Java EE?
>>
>> I suppose I am asking:
>>
>> "Is it OK for Java EE specifications/implementations to make
>> assumptions about the state of the SecurityManager/Policy without
>> respecting changes in their runtime state?"
> If you think there is an issue with the specifications, it would
> help if you could provide a reference to the
> specification content.
>
> that said, a perhaps overly simplistic answer to your question, is
> that EE 7 requires that every EE product be able to run with a
> security manager enabled. So for example, it would not be
> appropriate for an implementation to assume that a security
> manager will not (or at least never) be enabled. For prior
> releases of EE, one might conclude otherwise.
>
> Regarding the runtime or installation specific state of access
> control Policy (as enforced by the Policy system) there is an
> expectation that the Policy implementation enforce the policy as
> configured for the installation, with the additional requirement
> that every EE product provide a means for applications to be
> granted some specific permissions identified in the EE specification.
>
> EE 7 also added a new facility by which applications may declare
> the permissions that they require.
>
> I'll stop there for now,
>
> Ron
>
> --
>> *Raymond Augé*
>> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
>> Senior Software Architect
>> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>>
>
>
>
>
> --
> *Raymond Augé*
> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>