tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: atomicity problem in SecurityUtil.java
Date Sat, 21 Jul 2012 21:16:42 GMT
On 21/07/2012 21:32, Chris R wrote:
> Hi,
> 
> I am looking at SecurityUtil.java (
> http://www.docjar.com/html/api/org/apache/catalina/security/SecurityUtil.java.html)

It would be much better to reference the source from the canonical
location (the ASF svn repo) rather than some unverified third-party
location.

> and it seems that there may be a problem there. More specifically, in the
> execute method, getAttribute of Globals.SUBJECT_ATTR is obtained on a
> session
> and then it is set in a non-atomic fashion.

While that statement is true, you have not explained why this is a
problem in this particular case.

The are many examples in the archives of folks reporting a "problem"
based on an analysis of a small section of code without taking into
account how that code is actually used. The Tomcat developers (this one
at least) are more than a little fed up of these reports mainly because
those doing the reporting haven't done the research to figure out if
there is actually an issue or not.

> http://stackoverflow.com/questions/616601/is-httpsession-thread-safe-are-set-get-attribute-thread-safe-operations/616723#616723
> says that the get and set should be synchronized on a session.

No, it doesn't say that. The relevant text here is the specification
text that is quoted in that question.

> Is this going to be a problem?

You tell me.

> Should I file a bug?

How can you possibly file a bug if you don't know whether or not it is a
problem? Bug reports along the lines of "I think there might be a
problem..." are going to get closed very quickly as INVALID. Probably
with a comment to go and do some research to figure out if there is a
problem.

Having looked at this particular code, I see some potential
opportunities for simplifying things but no chance of a threading
problem. If you analysis reaches a different conclusion, please share it.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message