You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2001/01/14 19:46:27 UTC
[PROPOSAL] Tomcat 4 SecurityManager implementation
Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
Work on implementing this proposal is in progress. Comments please?
Tomcat 4 Java SecurityManager Proposal
Tomcat 4 will require the Java SecurityManager, use of the
SecurityManager will be optional when Tomcat is embedded in
another application.
Setting policies for internal Tomcat classes
--------------------------------------------
Security policies will be set using the tomcat.policy file. Security
checks will be based only on the codeSource of the class matching the
codeBase for JVM and Tomcat internal classes.
Example tomcat.policy entries affecting Tomcat internals
// javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
grant codeBase "file:${java.home}/jre/lib/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/server/-" {
permission java.security.AllPermission;
};
grant codeBase="file:${tomcat.home}/bin/-" {
permission java.security.AllPermission;
};
Setting policies for web application contexts
---------------------------------------------
A web application has its security based on either the default grant in
tomcat.policy or an entry for the context which uses the Context path
file URL as the codeBase. This policy will be in affect for any Class running
within the Context thread no matter which ClassLoader loaded the class
which triggered a security check. A default permission to read files in
the Context path is granted.
// Default permissions for a Context, all contexts have these permissions
grant {
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
};
// Additional Permissions for tomcat examples context
grant codeBase="file:${tomcat.home}/webapps/examples/- {
permission java.util.PropertyPermission "*", "read";
};
Security restrictions for using classes
---------------------------------------
StandardClassLoader will implement the SecurityManager.checkPackageAccess()
method to determine whether the ClassLoader has permission to access the
packages "sun.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"accessClassInPackage.{package name}", it will not be allowed to use a
Class in the package.
Security restrictions for defining classes
------------------------------------------
StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
method to determine whether the ClassLoader has permission to define a class
in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
If a Context doesn't have the RuntimePermission "*" or
"defineClassInPackage.{package name}", it will not be allowed to define
a Class in the package.
Changing security policies at runtime
-------------------------------------
Anytime a Context is reloaded the security policies will be refreshed
from the tomcat policy file.
StandardClassLoader
-------------------
All of the code for implementing system, restricted, and allowed
checks will be removed. This will be handled by the SecurityManager.
Remove the ability to configure a contexts classloader in the
server.xml Context element.
ApplicationSecurityManager
--------------------------
This Class is a replacement for the default SecurityManager and extends
class SecurityManager.
It does a normal permission check first, if that fails it takes additional
steps if the current thread is for a web application context.
When a Context is started or stopped it will need to register with
the ApplicationSecurityManager using methods setContext() and
removeContext().
Context threads will be named threads with the name set to the
string representing the file URL of the Context. i.e.
"file:/usr/local/tomcat/webapps/examples".
All other threads should be named with a name which doesn't
start with "file:".
The setContext() method will maintain a HashMap which maps
ApplicationSecurity to its thread name.
When a permission check fails the security manager will see if
the current thread or any of its parent threads are for a web
app context. If it is for a context, the permission check will
be done using the permissions for that web application context.
If the permission is for file read, permission will be granted
for the context root directory.
With the changes to jasper below, the normal permission check
will work for everything except when a web app context is
using a class from the shareable ClassLoader. So the overhead
of using the Thread naming conventions to perform the second
web app context security check should be minimal, most of the time
if the first permission check fails, the second one would also.
Jasper JSP class loading
------------------------
Jasper will have the old 1.1 compatability code stripped out.
The work directory will be moved inside the web application context
/WEB-INF/ directory. This will make security configuration easier
and security checks more efficient. The jasper work dir for a context
would be /WEB-INF/work/. This should be safe, other important files
which need to be protected from outside view are stored in
WEB-INF such as java properties files and class files.
/WEB-INF/work will not be added to the contexts class path.
Jasper will be modified so that each individual jsp page
will have its own URLClassLoader. When each jsp page has
its own URLClassLoader we can remove the need to munge and version
the jsp java and class file names. We can also create directory
paths in the work dir for the context that matches the jsp page
path in the context. This will make it easier to view the
generated source for a jsp page. When a jsp page is recompiled,
a new instance of the URLClassLoader for that page will be
created.
These changes will also prevent implementation of a SecurityManager
from coupling Jasper to Tomcat like it is in the 3.x branch.
Future enhancements
-------------------
See if it is possible and secure to let an individual
web application set its security policies in its own
policy file located in its /WEB-INF/ directory.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Sorry not to get this out earlier ... comments intermixed.
Glenn Nielsen wrote:
> Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
> Work on implementing this proposal is in progress. Comments please?
>
> Tomcat 4 Java SecurityManager Proposal
>
> Tomcat 4 will require the Java SecurityManager, use of the
> SecurityManager will be optional when Tomcat is embedded in
> another application.
>
Will it be optional when Tomcat 4 is run by itself (either standalone or behind
a
web server) as well?
>
> Setting policies for internal Tomcat classes
> --------------------------------------------
>
> Security policies will be set using the tomcat.policy file. Security
> checks will be based only on the codeSource of the class matching the
> codeBase for JVM and Tomcat internal classes.
>
> Example tomcat.policy entries affecting Tomcat internals
>
> // javac
> grant codeBase "file:${java.home}/lib/-" {
> permission java.security.AllPermission;
> };
>
> grant codeBase "file:${java.home}/jre/lib/-" {
> permission java.security.AllPermission;
> };
>
> grant codeBase="file:${tomcat.home}/server/-" {
> permission java.security.AllPermission;
> };
>
> grant codeBase="file:${tomcat.home}/bin/-" {
> permission java.security.AllPermission;
> };
>
Note - to be technically correct, references to "tomcat.home" in the entries
above
should be "catalina.home" for Tomcat 4, to be consistent with the system
property
definition that is actually used.
>
> Setting policies for web application contexts
> ---------------------------------------------
>
> A web application has its security based on either the default grant in
> tomcat.policy or an entry for the context which uses the Context path
> file URL as the codeBase. This policy will be in affect for any Class running
> within the Context thread no matter which ClassLoader loaded the class
> which triggered a security check. A default permission to read files in
> the Context path is granted.
>
> // Default permissions for a Context, all contexts have these permissions
> grant {
> permission java.util.PropertyPermission "file.separator", "read";
> permission java.util.PropertyPermission "path.separator", "read";
> permission java.util.PropertyPermission "line.separator", "read";
> };
>
Is this set of default permissions going to be easily configurable? I can
imagine
that this would be a popular choice for people who don't want to spend a lot of
time thinking about security. For example, you might want to grant all webapps
the
ability to connect to the network host and port required by your database
because
you use it in every app.
>
> // Additional Permissions for tomcat examples context
> grant codeBase="file:${tomcat.home}/webapps/examples/- {
> permission java.util.PropertyPermission "*", "read";
> };
Should the code base actually be restricted to ".../examples/WEB-INF/classes/-"
and
".../examples/WEB-INF/lib/-"? It means setting up two policy entries instead of
one if a particular app uses both JAR'd and unJAR'd classes, but I suspect that
is
somewhat unusual.
>
> Security restrictions for using classes
> ---------------------------------------
>
> StandardClassLoader will implement the SecurityManager.checkPackageAccess()
> method to determine whether the ClassLoader has permission to access the
> packages "sun.,org.apache.catalina.,org.apache.jasper.".
Is org.apache.jasper really special? It is loaded by the "Shared" classloader
(in
the Tomcat 4 classloader hierarchy) anyway, so it is already going to be
restricted.
And, a web app will need to be able to access these packages to utilize the JSP
servlet, and therefore execute JSP pages.
>
> If a Context doesn't have the RuntimePermission "*" or
> "accessClassInPackage.{package name}", it will not be allowed to use a
> Class in the package.
>
>
> Security restrictions for defining classes
> ------------------------------------------
>
> StandardClassLoader will implement the SecurityManager.checkPackageDefinition()
> method to determine whether the ClassLoader has permission to define a class
> in the packages "sun.,java.,javax.,org.apache.catalina.,org.apache.jasper.".
Same question re: specialness of Jasper, although I can see a stronger case for
prohibiting class *creation* in this package than class *access*.
>
> If a Context doesn't have the RuntimePermission "*" or
> "defineClassInPackage.{package name}", it will not be allowed to define
> a Class in the package.
>
>
> Changing security policies at runtime
> -------------------------------------
>
> Anytime a Context is reloaded the security policies will be refreshed
> from the tomcat policy file.
>
>
> StandardClassLoader
> -------------------
>
> All of the code for implementing system, restricted, and allowed
> checks will be removed. This will be handled by the SecurityManager.
>
+1
It's only there as a placeholder until security manager support is available.
>
> Remove the ability to configure a contexts classloader in the
> server.xml Context element.
>
This goes against the grain with respect to configurability -- all other
components
of Catalina are pluggable at startup time. How about if we include the
necessary
requirements in the API contracts for the org.apache.catalina.Loader
implementation
when running under a security manager?
>
> ApplicationSecurityManager
> --------------------------
>
> This Class is a replacement for the default SecurityManager and extends
> class SecurityManager.
>
> It does a normal permission check first, if that fails it takes additional
> steps if the current thread is for a web application context.
>
Have you had a chance to measure or estimate whether there is a performance hit
from using a security manager (versus not) yet?
>
> When a Context is started or stopped it will need to register with
> the ApplicationSecurityManager using methods setContext() and
> removeContext().
>
> Context threads will be named threads with the name set to the
> string representing the file URL of the Context. i.e.
> "file:/usr/local/tomcat/webapps/examples".
> All other threads should be named with a name which doesn't
> start with "file:".
>
Does this imply that a webapp based on a file system (as opposed to running from
a
WAR directly, for example) is required? Current work on the Resources component
for 4.1 is to support generalization of this.
>
> The setContext() method will maintain a HashMap which maps
> ApplicationSecurity to its thread name.
>
Currently, the threads used for request processing are created and managed by
the
Connector component. And, because threads are recycled, the same thread will be
used for different contexts at different times (unless we change the threading
mechanisms).
>
> When a permission check fails the security manager will see if
> the current thread or any of its parent threads are for a web
> app context. If it is for a context, the permission check will
> be done using the permissions for that web application context.
>
> If the permission is for file read, permission will be granted
> for the context root directory.
>
> With the changes to jasper below, the normal permission check
> will work for everything except when a web app context is
> using a class from the shareable ClassLoader. So the overhead
> of using the Thread naming conventions to perform the second
> web app context security check should be minimal, most of the time
> if the first permission check fails, the second one would also.
>
> Jasper JSP class loading
> ------------------------
>
> Jasper will have the old 1.1 compatability code stripped out.
>
+1
>
> The work directory will be moved inside the web application context
> /WEB-INF/ directory. This will make security configuration easier
> and security checks more efficient. The jasper work dir for a context
> would be /WEB-INF/work/. This should be safe, other important files
> which need to be protected from outside view are stored in
> WEB-INF such as java properties files and class files.
> /WEB-INF/work will not be added to the contexts class path.
>
-1 -- this would prevent being able to deploy a web app directly from a WAR
file,
or from BLOBs in a database (either of which will be supportable by writing a
custom Resources implementation).
>
> Jasper will be modified so that each individual jsp page
> will have its own URLClassLoader. When each jsp page has
> its own URLClassLoader we can remove the need to munge and version
> the jsp java and class file names.
+1 -- I don't like the munging that is currently needed.
> We can also create directory
> paths in the work dir for the context that matches the jsp page
> path in the context. This will make it easier to view the
> generated source for a jsp page. When a jsp page is recompiled,
> a new instance of the URLClassLoader for that page will be
> created.
>
> These changes will also prevent implementation of a SecurityManager
> from coupling Jasper to Tomcat like it is in the 3.x branch.
>
In 4.1, we're implementing a JNDI based DirContext for access to the resources.
Given that we have JNDI support, would it be possible to use that for looking up
the required security manager as well?
>
>
> Future enhancements
> -------------------
>
> See if it is possible and secure to let an individual
> web application set its security policies in its own
> policy file located in its /WEB-INF/ directory.
>
That would be cool, although I'm a little hesitant on the "in its /WEB-INF/
directory" part -- IMHO security should be imposed on a webapp by the container,
rather than being defined by the webapp itself.
Overall, great work Glenn! I am loking forward to having this functionality
implemented in Tomcat 4.
>
> Regards,
>
> Glenn
>
Craig
>
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Remy Maucherat <re...@apache.org>.
> -0. Why not make it optional for standard use as well? If I use Tomcat
> for development only, I'm not concerned with security and don't
> want to mess with policy files.
Same here. There's a switch for the naming features, and I think it should
be the same with the security manager.
Remy
RE: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Paulo Gaspar <pa...@krankikom.de>.
Tomcat would be a great tool to provide catalogs and presentations on
CD - with additional advantages if there are already web versions of
such applications. I know of a lot of people (me included) that would
like to use Tomcat this way.
I already implemented a proof of concept where a Delphi application
is used to configure and start a Java application using JNI and a JVM
on the CD (not installed in the PC). It works very well in Windows.
After this, using a small Delphi GUI to start Tomcat and run the
installed Web Browser over a Tomcat's site is quite trivial. But we
must be able to place work files on the temporary file directory or
we can't use JSPs.
I am not talking about a weird idea, it is something I am working on
and with commercial interest. I even researched, found and tested
(with very positive results) a java database (HypersonicSQL) to do
the catalog thing.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: hans@servlets.net [mailto:hans@servlets.net]On Behalf Of Hans
> Bergsten
> Sent: Sunday, January 14, 2001 22:05
> > The work directory will be moved inside the web application context
> > /WEB-INF/ directory. [...]
>
> -1. It should be possible to configure Tomcat so that the work
> directory is located under /tmp, or any other standard OS location
> for temporary files. Besides, creating files under /WEB-INF will
> not work if we one day support running applications straight from
> the WAR file.
>
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Glenn Nielsen wrote:
>
> Here is my proposal for implementing the Java SecurityManager in Tocmat 4.
> Work on implementing this proposal is in progress. Comments please?
>
> Tomcat 4 Java SecurityManager Proposal
>
> Tomcat 4 will require the Java SecurityManager, use of the
> SecurityManager will be optional when Tomcat is embedded in
> another application.
> [...]
-0. Why not make it optional for standard use as well? If I use Tomcat
for development only, I'm not concerned with security and don't
want to mess with policy files.
> [...]
> Jasper JSP class loading
> ------------------------
>
> Jasper will have the old 1.1 compatability code stripped out.
+1
> The work directory will be moved inside the web application context
> /WEB-INF/ directory. [...]
-1. It should be possible to configure Tomcat so that the work
directory is located under /tmp, or any other standard OS location
for temporary files. Besides, creating files under /WEB-INF will
not work if we one day support running applications straight from
the WAR file.
> Jasper will be modified so that each individual jsp page
> will have its own URLClassLoader. When each jsp page has
> its own URLClassLoader we can remove the need to munge and version
> the jsp java and class file names. We can also create directory
> paths in the work dir for the context that matches the jsp page
> path in the context. This will make it easier to view the
> generated source for a jsp page. When a jsp page is recompiled,
> a new instance of the URLClassLoader for that page will be
> created. [...]
+1. Great!
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Anil Vijendran <An...@eng.sun.com>.
Hi Glenn,
I had a few questions/comments on:
> Jasper JSP class loading
> The work directory will be moved inside the web application context
> /WEB-INF/ directory. This will make security configuration easier
> and security checks more efficient. The jasper work dir for a context
> would be /WEB-INF/work/. This should be safe, other important files
> which need to be protected from outside view are stored in
> WEB-INF such as java properties files and class files.
> /WEB-INF/work will not be added to the contexts class path.
Instead of this, how about having a parallel tree under a user-specified temp dir
with a workdir per web application?
This wouldn't work too well for webapps that are run from the WAR file itself.
(The WAR file could be expanded but that's an implementation detail and not
necessarily true.)
Also, I'm a bit wary about touching any part of the webapp that the user created.
What if I create a jar from the directory for that web application after you
created the tmp files?
As far as I can remember, the work directory needs to be added to the context's
classpath. Am I missing something?
> Jasper will be modified so that each individual jsp page
> will have its own URLClassLoader. When each jsp page has
> its own URLClassLoader we can remove the need to munge and version
> the jsp java and class file names. We can also create directory
> paths in the work dir for the context that matches the jsp page
> path in the context. This will make it easier to view the
> generated source for a jsp page. When a jsp page is recompiled,
> a new instance of the URLClassLoader for that page will be
> created.
At this point I don't have enough details to -1 this. But I'd suggest you consider
this before going ahead. Classloaders are heavyweight objects. JSP pages are
essentially like HTML pages. There can be many many of them. Do you want to have a
heavyweight classloader per JSP page (and one for every update of that page?)
--
Peace, Anil +<:-)
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Peter Donald wrote:
>
> At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
> > Tomcat 4 Java SecurityManager Proposal
> >
> >
> >Tomcat 4 will require the Java SecurityManager, use of the
> >SecurityManager will be optional when Tomcat is embedded in
> >another application.
>
> Why not always have it optional possibly determined by a system property
> value ? This way you won't have people complainig about slow down if they
> don't care about security ;) It will also be easier to integrate into other
> products.
>
> >Setting policies for web application contexts
> >---------------------------------------------
> >
> >A web application has its security based on either the default grant in
> >tomcat.policy or an entry for the context which uses the Context path
> >file URL as the codeBase. This policy will be in affect for any Class running
> >within the Context thread no matter which ClassLoader loaded the class
> >which triggered a security check. A default permission to read files in
> >the Context path is granted.
> >
> >// Default permissions for a Context, all contexts have these permissions
> >grant {
> > permission java.util.PropertyPermission "file.separator", "read";
> > permission java.util.PropertyPermission "path.separator", "read";
> > permission java.util.PropertyPermission "line.separator", "read";
> >};
> >
> >// Additional Permissions for tomcat examples context
> >grant codeBase="file:${tomcat.home}/webapps/examples/- {
> > permission java.util.PropertyPermission "*", "read";
> >};
>
> I have actually implemented something similar this in Avalon about 7 hours
> ago checking it in. Avalon has notion of .sars (Server Application
> Archives) which are very similar to .wars in idea. I was having some issues
> with JVM wide policy which you advocate above so I started playing around
> with a per-sar policy.
>
> To do this I had to subclass SecureClassLoader (I did this via
> URLClassLoader) and overide it's method
>
> protected PermissionCollection getPermissions( final CodeSource codeSource );
>
Duh! Somehow that method never popped out when I was looking at the URLClassLoader
class. That will make things even easier.
Your per application config below would work for Tomcat, but it would be nice
to see if a standard java policy file per web application could be used instead.
> I overode this to access a per-sar Policy object. If no policy was given it
> would give full access to the system. As I was embedding policy information
> in another file (an XML file) it looked something like
>
> <policy>
>
> <!--
> <keystore name="foo-keystore"
> location="file:${sar.home}${/}conf${/}keystore"
> type="JKS" />
> <grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
> key-store="foo-keystore">
> <permission class="java.io.FilePermission" target="/tmp/*"
> action="read,write" />
> </grant>
> -->
> <grant code-base="file:${sar.home}${/}blocks${/}*">
> <permission class="java.security.AllPermission" />
> </grant>
>
> <grant code-base="file:${sar.home}${/}lib${/}*">
> <permission class="java.security.AllPermission" />
> </grant>
>
> To do this I implemented AbstractPolicy (for generic facilities) and
> SarPolicy (for configuring it from XML file). I have attached the relevent
> classes just in case you are interested.
>
> >Future enhancements
> >-------------------
> >
> >See if it is possible and secure to let an individual
> >web application set its security policies in its own
> >policy file located in its /WEB-INF/ directory.
>
> This is a great facility - when implementing the equivelent for Avalon I
> found it vital for a usable system ;)
>
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: [PROPOSAL] Tomcat 4 SecurityManager implementation
Posted by Peter Donald <do...@apache.org>.
At 12:46 14/1/01 -0600, Glenn Nielsen wrote:
> Tomcat 4 Java SecurityManager Proposal
>
>
>Tomcat 4 will require the Java SecurityManager, use of the
>SecurityManager will be optional when Tomcat is embedded in
>another application.
Why not always have it optional possibly determined by a system property
value ? This way you won't have people complainig about slow down if they
don't care about security ;) It will also be easier to integrate into other
products.
>Setting policies for web application contexts
>---------------------------------------------
>
>A web application has its security based on either the default grant in
>tomcat.policy or an entry for the context which uses the Context path
>file URL as the codeBase. This policy will be in affect for any Class running
>within the Context thread no matter which ClassLoader loaded the class
>which triggered a security check. A default permission to read files in
>the Context path is granted.
>
>// Default permissions for a Context, all contexts have these permissions
>grant {
> permission java.util.PropertyPermission "file.separator", "read";
> permission java.util.PropertyPermission "path.separator", "read";
> permission java.util.PropertyPermission "line.separator", "read";
>};
>
>// Additional Permissions for tomcat examples context
>grant codeBase="file:${tomcat.home}/webapps/examples/- {
> permission java.util.PropertyPermission "*", "read";
>};
I have actually implemented something similar this in Avalon about 7 hours
ago checking it in. Avalon has notion of .sars (Server Application
Archives) which are very similar to .wars in idea. I was having some issues
with JVM wide policy which you advocate above so I started playing around
with a per-sar policy.
To do this I had to subclass SecureClassLoader (I did this via
URLClassLoader) and overide it's method
protected PermissionCollection getPermissions( final CodeSource codeSource );
I overode this to access a per-sar Policy object. If no policy was given it
would give full access to the system. As I was embedding policy information
in another file (an XML file) it looked something like
<policy>
<!--
<keystore name="foo-keystore"
location="file:${sar.home}${/}conf${/}keystore"
type="JKS" />
<grant signed-by="Fred" code-base="file:${sar.home}/blocks/*"
key-store="foo-keystore">
<permission class="java.io.FilePermission" target="/tmp/*"
action="read,write" />
</grant>
-->
<grant code-base="file:${sar.home}${/}blocks${/}*">
<permission class="java.security.AllPermission" />
</grant>
<grant code-base="file:${sar.home}${/}lib${/}*">
<permission class="java.security.AllPermission" />
</grant>
To do this I implemented AbstractPolicy (for generic facilities) and
SarPolicy (for configuring it from XML file). I have attached the relevent
classes just in case you are interested.
>Future enhancements
>-------------------
>
>See if it is possible and secure to let an individual
>web application set its security policies in its own
>policy file located in its /WEB-INF/ directory.
This is a great facility - when implementing the equivelent for Avalon I
found it vital for a usable system ;)