tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ANALIA DE PEDRO SANTAMARIA <100074...@alumnos.uc3m.es>
Subject Re: Restrict the use of JDK classes Tomcat 7 or 6
Date Wed, 20 Nov 2013 13:24:10 GMT
Thank you very much. Your answer has helped me a lot.


2013/11/20 Aurélien Terrestris <aterrestris@gmail.com>

> From what I understand in this doc, there is no specific resource
> management code anywhere and you must ensure that your application
> will call permission checking every time you are going to access the
> protected resource. Even for a web application, it must be considered
> as any other application, and it's in your own code to call such
> checking.
>
> The doc says : "Second, include these new classes with the application
> package." so include your class in your jar or war file.
>
> Yes, Tomcat is supposed to behave such any other JVM. However, you
> need to update the catalina.policy file for your own permission, and
> don't forget to call the security manager from the startup script (
> http://tomcat.apache.org/tomcat-7.0-doc/security-manager-howto.html )
>
> 2013/11/17 ANALIA DE PEDRO SANTAMARIA <100074002@alumnos.uc3m.es>:
> > Thank you very much. I have been working in creating my own permission
> and
> > I have some questions:
> >
> > - In the Java documentation says it is necessary to add a checkPermission
> > in the application's resource management code. My question is, when we
> are
> > working with web applications, which is the application's resource
> > management code? And where is it?
> >
> > - When I create my own permission class, where do I have to store it? In
> > order to the Security manager can find it.
> >
> > - I have read that it is not necessary to modify the Security Manager,
> when
> > we are creating a new permission for secure the JVM. When we are working
> > with Tomcat, and not with the JVM directly, is it the same? Or is it
> > necessary to modify the Tomcat's Security Manager?
> >
> > Thank you very much.
> >
> >
> >
> > 2013/11/12 Aurélien Terrestris <aterrestris@gmail.com>
> >
> >> Hello Analia
> >>
> >> I'm glad that you could play successfully with the Security Manager as
> >> I advised first :D
> >>
> >>
> >> About permissions, here you have a doc :
> >>
> >>
> >>
> http://docs.oracle.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc3.html#20211
> >>
> >> best regards
> >>
> >> 2013/11/11 ANALIA DE PEDRO SANTAMARIA <100074002@alumnos.uc3m.es>:
> >> > Hello,
> >> >
> >> > I have been working with the Security Manager and I think it is a good
> >> > aproximation of what I need, thank you very much for the advice. I
> have
> >> > read that it is possible to create your own Permission class, but I
> >> haven't
> >> > found any documentation or example. Could anybody tell me where I can
> >> find
> >> > information about create a Permission class?
> >> >
> >> > Thank you very much.
> >> >
> >> >
> >> > 2013/10/23 Caldarale, Charles R <Chuck.Caldarale@unisys.com>
> >> >
> >> >> > From: Christopher Schultz [mailto:chris@christopherschultz.net]
> >> >> > Subject: Re: Restrict the use of JDK classes Tomcat 7 or 6
> >> >>
> >> >> > When you say "Java classes", are you talking about re-defining
> >> >> > something like java.lang.String? If so, then the servlet spec
(3.0:
> >> >> > 10.7.2) prohibits web applications from loading classes from any
of
> >> >> > these packages from a web application class loader.
> >> >> >   java.*
> >> >> >   javax.*
> >> >> > Looking at current trunk, Tomcat appears to take a lazy view and
> just
> >> >> > look for these two classes:
> >> >> >   javax.servlet.Servlet
> >> >> >   javax.el.Expression
> >> >> > So it looks like you might be able to redefine java.lang.String
if
> you
> >> >> > want.
> >> >>
> >> >> As I recall, the JVM itself prevents loading of java.* classes from
> >> >> anywhere other than the registered JRE jar locations.  Not sure about
> >> >> javax.* classes.
> >> >>
> >> >>  - Chuck
> >> >>
> >> >>
> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
> PROPRIETARY
> >> >> MATERIAL and is thus for use only by the intended recipient. If you
> >> >> received this in error, please contact the sender and delete the
> e-mail
> >> and
> >> >> its attachments from all computers.
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message