You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2001/01/19 23:00:22 UTC

[PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades

BACKGROUND:

One of the unique (AFAIK) features of Tomcat 3.2 as a servlet container is the
fact that you can choose to run Tomcat under a Java SecurityManager (when
running under a Java2 JDK), with corresponding fine-grained control over the
resources that a particular web application can access.  In addition, the
security manager can be used to constrain an application from accessing Tomcat
internals (for example, by trying to cast the HttpServletRequest it receives
back to the Tomcat internal implementation class).

This feature has long been on the wish list for 4.0, and recently Glenn Nielsen
<gl...@voyager.apg.more.net> has volunteered to complete it.  Those involved in
3.2 will recall that Glenn was also the primary "mover and shaker" in
implementing the security manager feature there.

Currently, as a stopgap security measure, Tomcat 4.0's web application
classloader implements some specific restrictions on access to particular Java
packages -- for example, an application level class is not allowed to load any
class in the org.apache.catalina.* hierarchy.  While this does indeed protect
the internal implementation classes, it becomes redundant once running under a
security manager is installed -- the checkPackageAccess() method serves this
purpose in a much more powerful and controlled approach.


THE CURRENT SITUATION:

Currently, the internal object that implements the Java Servlet API objects
exposed to application components implement the corresponding API interfaces
directly.  For example:

    public class StandardSession
        implements HttpSession, Session, Serializable {

        ...

    }

so that, when an application calls request.getSession, an instance of this class
(suitably cast to HttpSession) is returned.  The application cannot cast the
returned object to an org.apache.catalina.session.StandardSession, because of
the customized restrictions implemented in the web application class loader.

Switching to the security manager for protection requires a change in this
approach, because the security permissions of a StandardSession are based on
where *that* class was loaded from, and not from the interfaces it implements.


THE PROPOSAL:

For each Servlet API interface that represents an internal Catalina object
exposed to an application object, create a new
org.apache.catalina.facade.XxxxxFacade class according to the following basic
pattern:

* Pass the internal object to the constructor (the facade
  will be a wrapper around it).

* Implement the appropriate servlet API interface (so the
  facade object can be passed to application components)

* For each public method in the interface, implement a doPrivileged
  block that calls the corresponding method on the underlying
  internal Catalina object.

For example, the session facade object would look something like this:

    package org.apache.catalina.facade;

    import javax.servlet.http.HttpSession;
    import org.apache.catalina.Session;

    public class SessionFacade implements HttpSession {

        protected Session session = null;

        public SessionFacade(Session session) {
            super();
            this.session = session;
        }

        public String getId() {
            AccessController.doPrivileged(
                new PrivilegedAction()
                    {
                        public Object run() {
                            return (session.getId());
                        }
                    }
            );
        }

        ... same pattern for all other public methods ...

    }

Additionally, the logic that implements request.getSession() would be modified
to look up and return the facade object associated with the current session,
instead of the actual StandardSession object itself.


RECOMMENDATION:

Implementing the remainder of the security manager logic in Tomcat 4.0 was part
of the agreed-upon original release plan, and Glenn has volunteered to undertake
the other changes necessary to Catalina and Jasper to make this happen (and
there are lots of them -- thanks Glenn!).  It seems that adding the facade
classes, according to the pattern described above, will be necessary to complete
this work.

Therefore, I feel we should implement this change in Tomcat 4.0, and create a
new beta to allow testing of the results.  This can be done in the same beta
release with the changes for the Valve API if that is also agreed upon.

However, I'm currently committed on other activities.  In order to achieve these
changes in a timely manner, I'm looking for a volunteer to implement these
changes, if the proposal is accepted.

Comments?

Craig

Re: [PROPOSAL] Tomcat 4.0-beta API Change: Security Manager Facades

Posted by Jason Brittain <ja...@olliance.com>.

Remy Maucherat wrote:

> Quoting "Craig R. McClanahan" <Cr...@eng.sun.com>:
> 
>> org.apache.catalina.facade.XxxxxFacade
> 
> 
> Nice package name. I wonder where you got it :)
> 

:)

Unless I understand wrong, isn't a "facade" already a well known feature
that allows Tomcat 3.x to use more than one different version of the
Servlet API?  Am I wrong and it does more than just that?

If I'm right, that means you're proposing to use the name "facade"
in the Tomcat 4 codebase to have a completely different meaning,
right?  If this is the case, could we instead use a different name?  I'm
not sure what name I would use..  "sandbox" maybe?

-- 
Jason Brittain
Software Engineer, Olliance Inc.        http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

welcome-file

Posted by Jayesh <ja...@yahoo.com>.

I tried configuring welcome-file attribute like below.
    <welcome-file-list>
 <welcome-file>
            HomePage.jsp
        </welcome-file>
    </welcome-file-list>

It doesn't work.

Please help.
Jayesh


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com