The doPrivileged() for getting a session is in the CoyoteRequest public getSession()
method which is implemented as required by ServletRequest and HttpServletRequest.

The getSession() can be called by a web application.  The doPrivileged() block would
be required to exist either where it currently is or in each individual implementation
of Manager/Store.  If it wasn't there getting a session would fail if the web app
were not granted the necessary permissions.  Permissions I would not want to grant to 
it.

IMHO it is best left where it is.  If someone were to implement a custom Manager/Store
then the permissions allowed at that point would be the intersection of those 
permissions
granted to catalina and those granted to the codeBase for the custom Manager/Store.
So you still have your fine grained control of security policies.
That is how it should work.

-1 for changing/removing the doPrivileged()

Regards,

Glenn

Jean-Francois Arcand wrote:
> Hi,
> 
> In o.a.c.tomcat5.CoyoteRequest (same in tomcat4), there is a doPrivilege 
> block that grant the doGetSession method. This method delegate the logic 
> to the o.a.c.Manager instance. A Manager can (but it's not required) 
> uses a o.a.c.Store object . The Manager and the Store object may need 
> special privileges when handling session persistance (see 
> o.a.c.session.FileStore for an example).
> 
> I would recommend we remove the doPrivilege block from CoyoteRequest and 
> delegate the doPrivilege call to the Manager (or the Store) instance. 
> That will allow better fine grained security check. Only the required 
> operations should be granted (right now every Manager is granted -> so 
> every Store instance!). As an example, o.a.c.session.FileStore does not 
> contains any security checks in its current implementation, and IMO, it 
> should.
> 
> The contract between the Manager and CoyoteRequest will have to be 
> documented somewhere since Manager written for Tomcat 4 may no longer 
> works. The catalina.policy file can then be used to give special 
> privileges to ManagerX, but not to ManagerY (same for Store instance or 
> whatever objects is used), based on codebase.
> 
> Any recommendations/objections to the modification?
> 
> Thanks,
> 
> -- Jeanfrancois
> 
> P.S Right now, if you run Tomcat with the default Security manager, the 
> doPrivilege block is useless. For performance reason, we should avoid 
> this call.
> 
> 
> -- 
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to