You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by David Sean Taylor <da...@bluesunrise.com> on 2001/03/01 08:03:57 UTC
RE: tomcat security and proxies
Santiago,
This is great information and research.
Besides debugging, where can I find indepth information on security in a
servlet container?
I have the 2.3 spec, but there isn't really much there.
Thanks,
David
> -----Original Message-----
> From: jetspeed@list.working-dogs.com
> [mailto:jetspeed@list.working-dogs.com]On Behalf Of Santiago Gala
> Sent: Monday, February 26, 2001 2:28 PM
> To: JetSpeed
> Subject: FYI: tomcat security and proxies
>
>
> While checking tomcat with security, I noticed the following
> in server.xml:
>
> "If security manager is enabled, you'll have read perms.
> in the webapps dir and read/write in the workdir."
>
> I quote this because this question was made by David some time ago.
>
> The set of properties needed for Jetspeed to run with security on
> under tomcat 3.2.1 and turbine close to cvs HEAD is (approx.):
>
> grant codeBase "file:${tomcat.home}/webapps/jetspeed" {
>
> //I'm not sure about this one is needed
> permission java.io.FilePermission
> "${tomcat.home}/webapps/jetspeed/WEB-INF/-", "read";
>
> //Possitively yes (TR.p include using relative path)
> permission java.io.FilePermission
> "JetspeedResources.properties",
> "read";
>
> //Needs delete to handle DB
> permission java.io.FilePermission
> "${tomcat.home}/webapps/jetspeed/WEB-INF/db/*", "read,write,delete";
>
> permission java.io.FilePermission
> "${tomcat.home}/webapps/jetspeed/WEB-INF/cache/*",
> "read,write,delete";
>
> permission java.io.FilePermission
> "${tomcat.home}/webapps/jetspeed/WEB-INF/log/*", "read,write,delete";
>
> //Possibly redundant
> permission java.io.FilePermission
> "${tomcat.home}/webapps/jetspeed/WEB-INF/psml/*", "read,write,delete";
>
> //To be able to send mail (not tested)
> permission java.net.SocketPermission "localhost:25","connect";
>
> //To be able to run cache and feeds
> permission java.net.SocketPermission "*","connect";
>
> //To be able to say setFollowRedirects() in cache code
> permission java.lang.RuntimePermission "setFactory";
>
> //Xalan needs this to check for Extensions...
> permission java.lang.RuntimePermission "getClassLoader";
>
> //Turbine needs this (TurbineServletService) to handle
> servlet2.0
> //Turbine needs this to get RunDatas from Factory
> permission java.lang.RuntimePermission "accessDeclaredMembers";
>
> //The way we ask for permissions in admin portlet...
> permission java.util.PropertyPermission "*", "read,write";
>
> //Castor will fail if this is not here...
> permission java.io.FilePermission
> "${java.home}/lib/castor.properties", "read";
> //For jaxp
> permission java.io.FilePermission
> "${java.home}/lib/jaxp.properties", "read";
>
>
> };
>
> I'm not completely sure about all the permissions, but this gives an
> idea of the complexity of having Jetspeed running under a security
> managed servlet container. I had to do some debugging to find some of
> the permissions needed... There could be "hidden" permissions, that I
> have not found yet. Note that most of these permissions do
> not surface
> in the Jetspeed.log, as we don't always test for
> RuntimeErrors and some
> errors are wrapped.
>
> The debugging allowed me to find a solution for the "proxy"
> problem, at
> least for jdk1.3.1beta (I don't know if it was there in older
> jdks, but
> it may be worth try). http.nonProxyHosts sets hosts for which
> there is
> no proxy, http.proxyHost is the proxy for http, proxyHost is
> the generic
> proxy. This are the security checks while the cache refreshes
> an entry:
>
> access: access allowed (java.net.SocketPermission
> network54.com resolve)
> access: access allowed (java.net.SocketPermission 64.70.16.71:80
> connect,resolve)
> access: access allowed (java.util.PropertyPermission
> http.nonProxyHosts
> read)
> access: access allowed (java.util.PropertyPermission
> http.proxyHost read)
> access: access allowed (java.util.PropertyPermission proxyHost read)
> (use -Djava.security.debug=access /all for a very verbose log)
>
> That's all folks!
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: jetspeed-on@list.working-dogs.com
> To unsubscribe: jetspeed-off@list.working-dogs.com
> Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
> List Help?: jon@working-dogs.com
>
>
RE: tomcat security and proxies
Posted by David Sean Taylor <da...@bluesunrise.com>.
> I started looking at the problem because I think that the whole
> idea of the .war is great for having distributed webs "hosted".
>
> For instance, I could have my deployment copy, and servlet engines in
> all the major backbones would check and reload my app every
> time it changes.
>
> Some Virtual Server system would redirect automagically the
> requests to the closest
> server (in load/latency terms). If, for instance, I go to a
> live TV show in the US, my provider
> could react to the load and put 100 more servers with my
> webapp while the traffic peak goes on...
>
> For this paradise to happen, it is just a matter of having
> Servlet 2.2 + session migration + some magical
> DB system I have not found yet. If we don't think
> distributed, it is simpler. I would receive a message like:
>
> >Thanks for purchasing our ACME webapp service. Please take
> note that your configuration is:
> >
> >webapp: taken from <yourdeploymenturl>
> >db connection:
> >url: jdbc:www.xxx.com/db/sgala/
> >username: sgala
> >password: don't
> >
> >You have 100 MBytes available for this database,
> > and 40 MBytes webapp space.
>
> Just dreaming :)
>
yes, but thats how great ideas start, from dreams
this sounds very possible for a self-contained webapp.
i believe its a solid idea, and shared session state is not new.
the small problem i see is external resources, as you obviously pointed out,
databases
that and you will need to have some kind of description, discover and deploy
standard, something like UDDI with deployment
> If you start thinking about this scenario, security comes to
> mind very fast. Specially since
> the same VM can be shared by a lot of different webapps.
>
> This is one of my visions (don't need to drink to see it,
> maybe I smoke
> too much :)
>
when you told me you smoked, i was thinking of cigarettes :)
Re: tomcat security and proxies
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
> Santiago,
>
> This is great information and research.
> Besides debugging, where can I find indepth information on security in a
> servlet container?
> I have the 2.3 spec, but there isn't really much there.
>
I don't think there is too much information. Ask Craig or some other
Tomcat developer.
I started looking at the problem because I think that the whole
idea of the .war is great for having distributed webs "hosted".
For instance, I could have my deployment copy, and servlet engines in
all the major backbones would check and reload my app every time it changes.
Some Virtual Server system would redirect automagically the requests to the closest
server (in load/latency terms). If, for instance, I go to a live TV show in the US, my provider
could react to the load and put 100 more servers with my webapp while the traffic peak goes on...
For this paradise to happen, it is just a matter of having Servlet 2.2 + session migration + some magical
DB system I have not found yet. If we don't think distributed, it is simpler. I would receive a message like:
>Thanks for purchasing our ACME webapp service. Please take note that your configuration is:
>
>webapp: taken from <yourdeploymenturl>
>db connection:
>url: jdbc:www.xxx.com/db/sgala/
>username: sgala
>password: don't
>
>You have 100 MBytes available for this database,
> and 40 MBytes webapp space.
Just dreaming :)
If you start thinking about this scenario, security comes to mind very fast. Specially since
the same VM can be shared by a lot of different webapps.
This is one of my visions (don't need to drink to see it, maybe I smoke
too much :)