You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Raymond Auge <ra...@liferay.com> on 2013/08/18 18:15:17 UTC
Constants.IS_SECURITY_ENABLED
Hello everyone,
My name is Raymond Auge and this is my first message to the list. Hopefully
I follow protocol correctly. Let me know if I don't.
----
org.apache.jasper.Constants.IS_SECURITY_ENABLED
is a global (static final) constant. As such it is evaluated exactly once.
Since Jasper is typically provided as part of the app server this means
it's impossible for some later module to enable Java security dynamically.
The Java security API is clearly dynamic. It allows for the creation of
both security managers and policies created and registered at runtime.
The JVM itself always performs dynamic evaluation of security (normally the
very same null check which is stored by IS_SECURITY_ENABLED.
Scenario demonstrating a problem:
1) start tomcat normally (no security)
2) assuming any normal app is initialized, a JspRuntimeContext will be
created and at first invocation
Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);
is evaluated.
3) deploy some later component (ie. a webapp) which does:
System.setSecurityManager(new SecurityManager());
4) from that point, all Jasper code will provide the incorrect state, app
server wide
I realize this is a very long standing mechanism. I'm wondering what would
be the odds of accepting a patch which enables a dynamic check as opposed
to global constant.
A further change would be required to initialize security dynamically which
I think could be done simply enough without incurring significant
performance issue.
BTW, this issue affects every app server which uses Jasper (including users
of the JSR RI in the Glassfish project)
Any thoughts?
Sincerely,
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Constants.IS_SECURITY_ENABLED
Posted by Raymond Auge <ra...@liferay.com>.
Fair enough!
Thank you
On Mon, Aug 19, 2013 at 4:49 PM, Mark Thomas <ma...@apache.org> wrote:
> On 19/08/2013 21:11, Raymond Auge wrote:
> > On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 18/08/2013 20:06, Raymond Auge wrote:
> >>> On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
> >>
> >>>> First of all this is a container concern, not an application
> >>>> concern. Secondly, a security manager applies JVM wide.
> >>
> >
> > I agree 100%
> >
> > However, in this case the JSP impl is preventing the container itself
> from
> > making any such change!
>
> No it isn't. Tomcat provides configuration options to start the
> container with or without a SecurityManager. Tomcat provides no options
> to configure the SecurityManager dynamically.
>
> > The JSP impl has no business making the decision on
> > behalf of either the container or JVM.
>
> The JSP implementation is part of the container. Design decisions made
> for one can have an impact on the other.
>
> >> <snip/>
> >>
> >>> Nowhere in any specification is this stated!
> >>
> >> Maybe not in language that is immediately clear but this is stated in
> >> the J2EE platform specification. (section EE.6.2.2)
> >
> >
> > I infer no such meaning from the EE spec.
>
> You miss my point. My point is that this is a container concern. The
> spec makes that clear.
>
> > Furthermore, why couldn't any of "EE.6.2.2.3 System Administrator’s
> > Responsibilities" be implemented as a web application designed to
> simplify
> > management of these responsibilities?
>
> They could. Tomcat does not implement that way.
>
> > As long as the policies imposed by the administrator are respected, why
> > does it matter where policy management takes place?
>
> It doesn't. That is a design choice for container implementers.
>
> > In fact, if I'm not mistaken one significant point for the JVM's Security
> > API being "dynamic" as opposed to being completely "static", is so that
> > management can be performed, either programmatically, or
> > remotely (otherwise why would these APIs even exist were that not the
> case).
> >
> > <snip/>
> >
> > .. none of which explains why the Jasper retains static final check of
> > whether security manager is enabled or not.
>
> Because Tomcat only provides options to configure a SecurityManager on
> start-up.
>
> If Tomcat was going to implement dynamic configuration of the
> SecurityManager then the various IS_SECURITY_ENABLED constants would
> need to be removed.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Constants.IS_SECURITY_ENABLED
Posted by Mark Thomas <ma...@apache.org>.
On 19/08/2013 21:11, Raymond Auge wrote:
> On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas <ma...@apache.org> wrote:
>
>> On 18/08/2013 20:06, Raymond Auge wrote:
>>> On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>>>> First of all this is a container concern, not an application
>>>> concern. Secondly, a security manager applies JVM wide.
>>
>
> I agree 100%
>
> However, in this case the JSP impl is preventing the container itself from
> making any such change!
No it isn't. Tomcat provides configuration options to start the
container with or without a SecurityManager. Tomcat provides no options
to configure the SecurityManager dynamically.
> The JSP impl has no business making the decision on
> behalf of either the container or JVM.
The JSP implementation is part of the container. Design decisions made
for one can have an impact on the other.
>> <snip/>
>>
>>> Nowhere in any specification is this stated!
>>
>> Maybe not in language that is immediately clear but this is stated in
>> the J2EE platform specification. (section EE.6.2.2)
>
>
> I infer no such meaning from the EE spec.
You miss my point. My point is that this is a container concern. The
spec makes that clear.
> Furthermore, why couldn't any of "EE.6.2.2.3 System Administrator’s
> Responsibilities" be implemented as a web application designed to simplify
> management of these responsibilities?
They could. Tomcat does not implement that way.
> As long as the policies imposed by the administrator are respected, why
> does it matter where policy management takes place?
It doesn't. That is a design choice for container implementers.
> In fact, if I'm not mistaken one significant point for the JVM's Security
> API being "dynamic" as opposed to being completely "static", is so that
> management can be performed, either programmatically, or
> remotely (otherwise why would these APIs even exist were that not the case).
>
> <snip/>
>
> .. none of which explains why the Jasper retains static final check of
> whether security manager is enabled or not.
Because Tomcat only provides options to configure a SecurityManager on
start-up.
If Tomcat was going to implement dynamic configuration of the
SecurityManager then the various IS_SECURITY_ENABLED constants would
need to be removed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Constants.IS_SECURITY_ENABLED
Posted by Raymond Auge <ra...@liferay.com>.
On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas <ma...@apache.org> wrote:
> On 18/08/2013 20:06, Raymond Auge wrote:
> > On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
>
> >> First of all this is a container concern, not an application
> >> concern. Secondly, a security manager applies JVM wide.
>
I agree 100%
However, in this case the JSP impl is preventing the container itself from
making any such change! The JSP impl has no business making the decision on
behalf of either the container or JVM.
>
> <snip/>
>
> > Nowhere in any specification is this stated!
>
> Maybe not in language that is immediately clear but this is stated in
> the J2EE platform specification. (section EE.6.2.2)
>
I infer no such meaning from the EE spec. I fact the spec seems to go out
of it's way to avoid claiming what is NOT allowed and only talks about what
is minimally required by each of the stackholders.
Furthermore, why couldn't any of "EE.6.2.2.3 System Administrator’s
Responsibilities" be implemented as a web application designed to simplify
management of these responsibilities?
As long as the policies imposed by the administrator are respected, why
does it matter where policy management takes place?
In fact, if I'm not mistaken one significant point for the JVM's Security
API being "dynamic" as opposed to being completely "static", is so that
management can be performed, either programmatically, or
remotely (otherwise why would these APIs even exist were that not the case).
<snip/>
.. none of which explains why the Jasper retains static final check of
whether security manager is enabled or not.
Sincerely,
- Ray
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Constants.IS_SECURITY_ENABLED
Posted by Mark Thomas <ma...@apache.org>.
On 18/08/2013 20:06, Raymond Auge wrote:
> On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
>> Web applications have no business trying to configure a security
>> manager. First of all this is a container concern, not an application
>> concern. Secondly, a security manager applies JVM wide. An application
>> has no way to determine how to configure a security manager to enable
>> any other applications to operate correctly. This is why it is a
>> container concern where the deployer can determine a) if they require a
>> security manager in their environment (something else an application has
>> no way of determining) and b) what an appropriate security policy is for
>> their environment.
<snip/>
> Nowhere in any specification is this stated!
Maybe not in language that is immediately clear but this is stated in
the J2EE platform specification. (section EE.6.2.2)
> Why can't a web application declare and provide a security manager?
Think about it. If an application configures a security manager it also
needs to define the security policy. The application will know what
permissions it needs but it will not know:
- what permissions the container needs
- what permissions other applications deployed in the container need
The likely result of an application configuring a security manager will
be a long series of security exceptions and a significant - if not total
- loss of functionality.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Constants.IS_SECURITY_ENABLED
Posted by Raymond Auge <ra...@liferay.com>.
On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote:
> On 18/08/2013 17:34, Raymond Auge wrote:
> > I've filed a bugs:
> >
> > https://java.net/jira/browse/JSP-37
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=55446
>
> And I have closed the Tomcat one as invalid.
>
> > On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge <raymond.auge@liferay.com
> >wrote:
> >> Since Jasper is typically provided as part of the app server this means
> >> it's impossible for some later module to enable Java security
> dynamically.
>
> Correct. This is by design.
>
> >> The Java security API is clearly dynamic. It allows for the creation of
> >> both security managers and policies created and registered at runtime.
> >>
> >> The JVM itself always performs dynamic evaluation of security (normally
> >> the very same null check which is stored by IS_SECURITY_ENABLED.
>
> Irrelevant.
>
> >> Scenario demonstrating a problem:
> >>
> >> 1) start tomcat normally (no security)
> >> 2) assuming any normal app is initialized, a JspRuntimeContext will be
> >> created and at first invocation
> >>
> >> Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);
> >>
> >> is evaluated.
> >>
> >> 3) deploy some later component (ie. a webapp) which does:
> >>
> >> System.setSecurityManager(new SecurityManager());
>
> Web applications have no business trying to configure a security
> manager. First of all this is a container concern, not an application
> concern. Secondly, a security manager applies JVM wide. An application
> has no way to determine how to configure a security manager to enable
> any other applications to operate correctly. This is why it is a
> container concern where the deployer can determine a) if they require a
> security manager in their environment (something else an application has
> no way of determining) and b) what an appropriate security policy is for
> their environment.
>
Nowhere in any specification is this stated! Why can't a web application
declare and provide a security manager?
>
> >> I realize this is a very long standing mechanism. I'm wondering what
> would
> >> be the odds of accepting a patch which enables a dynamic check as
> opposed
> >> to global constant.
>
> Zero. I would veto any commit that applied such a patch.
>
> >> A further change would be required to initialize security dynamically
> >> which I think could be done simply enough without incurring significant
> >> performance issue.
> >>
> >> BTW, this issue affects every app server which uses Jasper (including
> >> users of the JSR RI in the Glassfish project)
> >>
> >> Any thoughts?
>
> You haven't thought through the implications of your proposal nor the
> practicalities of how it would work. The point being that it couldn't work.
>
> Mark
>
Thanks for your support.
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)
Re: Constants.IS_SECURITY_ENABLED
Posted by Mark Thomas <ma...@apache.org>.
On 18/08/2013 17:34, Raymond Auge wrote:
> I've filed a bugs:
>
> https://java.net/jira/browse/JSP-37
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55446
And I have closed the Tomcat one as invalid.
> On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge <ra...@liferay.com>wrote:
>> Since Jasper is typically provided as part of the app server this means
>> it's impossible for some later module to enable Java security dynamically.
Correct. This is by design.
>> The Java security API is clearly dynamic. It allows for the creation of
>> both security managers and policies created and registered at runtime.
>>
>> The JVM itself always performs dynamic evaluation of security (normally
>> the very same null check which is stored by IS_SECURITY_ENABLED.
Irrelevant.
>> Scenario demonstrating a problem:
>>
>> 1) start tomcat normally (no security)
>> 2) assuming any normal app is initialized, a JspRuntimeContext will be
>> created and at first invocation
>>
>> Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);
>>
>> is evaluated.
>>
>> 3) deploy some later component (ie. a webapp) which does:
>>
>> System.setSecurityManager(new SecurityManager());
Web applications have no business trying to configure a security
manager. First of all this is a container concern, not an application
concern. Secondly, a security manager applies JVM wide. An application
has no way to determine how to configure a security manager to enable
any other applications to operate correctly. This is why it is a
container concern where the deployer can determine a) if they require a
security manager in their environment (something else an application has
no way of determining) and b) what an appropriate security policy is for
their environment.
>> I realize this is a very long standing mechanism. I'm wondering what would
>> be the odds of accepting a patch which enables a dynamic check as opposed
>> to global constant.
Zero. I would veto any commit that applied such a patch.
>> A further change would be required to initialize security dynamically
>> which I think could be done simply enough without incurring significant
>> performance issue.
>>
>> BTW, this issue affects every app server which uses Jasper (including
>> users of the JSR RI in the Glassfish project)
>>
>> Any thoughts?
You haven't thought through the implications of your proposal nor the
practicalities of how it would work. The point being that it couldn't work.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Constants.IS_SECURITY_ENABLED
Posted by Raymond Auge <ra...@liferay.com>.
I've filed a bugs:
https://java.net/jira/browse/JSP-37
https://issues.apache.org/bugzilla/show_bug.cgi?id=55446
On Sun, Aug 18, 2013 at 12:15 PM, Raymond Auge <ra...@liferay.com>wrote:
> Hello everyone,
>
> My name is Raymond Auge and this is my first message to the list.
> Hopefully I follow protocol correctly. Let me know if I don't.
>
> ----
>
> org.apache.jasper.Constants.IS_SECURITY_ENABLED
>
> is a global (static final) constant. As such it is evaluated exactly once.
>
> Since Jasper is typically provided as part of the app server this means
> it's impossible for some later module to enable Java security dynamically.
>
> The Java security API is clearly dynamic. It allows for the creation of
> both security managers and policies created and registered at runtime.
>
> The JVM itself always performs dynamic evaluation of security (normally
> the very same null check which is stored by IS_SECURITY_ENABLED.
>
> Scenario demonstrating a problem:
>
> 1) start tomcat normally (no security)
> 2) assuming any normal app is initialized, a JspRuntimeContext will be
> created and at first invocation
>
> Constants.IS_SECURITY_ENABLED = (System.getSecurityManager() != null);
>
> is evaluated.
>
> 3) deploy some later component (ie. a webapp) which does:
>
> System.setSecurityManager(new SecurityManager());
>
> 4) from that point, all Jasper code will provide the incorrect state, app
> server wide
>
> I realize this is a very long standing mechanism. I'm wondering what would
> be the odds of accepting a patch which enables a dynamic check as opposed
> to global constant.
>
> A further change would be required to initialize security dynamically
> which I think could be done simply enough without incurring significant
> performance issue.
>
> BTW, this issue affects every app server which uses Jasper (including
> users of the JSR RI in the Glassfish project)
>
> Any thoughts?
>
>
> Sincerely,
> --
> *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)