Jean-Francois Arcand wrote: > > > Glenn Nielsen wrote: > >> Costin Manolache wrote: >> >>> I'm in the middle on this one - but I would vote for Jean-Francois >>> proposal. >>> >>> Glen is right, it is possible to restrict individual managers >>> using the policy. >>> However as geenral programming it is better to keep the >>> doPrivileged block as small as possible - and have each individual >>> manager that needs to change the permission context >>> do that for the specific areas where this is needed, instead >>> of a global aproach. >> >> >> >> In general I agree, keeping the amount of code within a doPrivileged() >> block to a minimum is a good practice. That makes it less likely that >> the code which calls a method which uses doPrivileged can compromise >> security. >> That is not the case for getSession() where the only thing passed to the >> method is a boolean for create and the Manager gets the JSESSIONID cookie >> from the request. >> >> Removing doPrivileged() from where it currently is will force alot of >> other work to be done. And will then require anyone who implements a >> custom Manager/Store to wrap their code in doPrivileged() also. >> >> I don't see any security risks from the current implemenation, so why >> change it? >> If you can show me an exploit that this change would fix I would be >> all for it. > > > Eum...why waiting for a security issue (joke: we are not Microsoft ;-) > ). Spending time trying to demonstrate a security hole will take as much > time as reducing the doPrivilege block. I understand your point but > still, I consider the doPrivilege block too large. And still, when > Tomcat is used as it is (with the default SecurityManager), the > doPrivilege block is *not* required. For a lot of Tomcat users, we are > forcing a doPrivilege block..... > > Correct me if I'm wrong, but only JDBCStore and FileStore needs to be > changed. I volonteer to make the extra work. >
It isn't the size of the block of code that matters... Its how the code within that block could pose a security risk. From a security standpoint I don't see any possible exploits. There may be a slight performance improvement for those requests where a session is used by moving the doPrivileged out of the critical path. From just a performance perspective I would want to profile Tomcat to determine where efforts could be best spent to improve performance. Then spend time on the biggest bottleneck to performance found rather than on this. It will require that the documentation for how to write a Manager/Store be updated to discuss this issue. It will also require alot of testing to make sure that you find _all_ the places where a doPrivileged is needed. That means trying all the Manager/Store implementations which come with Tomcat and trying different configuration options. Sounds like alot of work to me. I know I don't have the time to make a change like this for the minimal benefit I see. But if you have the time and want to implement this, go ahead, its your itch. :-) Regards, Glenn -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
