On 02/04/2015 05:19 PM, Chris Hegarty wrote:
On 04/02/15 16:01, Peter Levart wrote:
On 02/04/2015 04:45 PM, Alan Bateman wrote:
On 04/02/2015 15:10, Weijun Wang wrote:
It should be checked, otherwise a non-initialized parent object comes
into being.
In general then permission checks in constructors are a bad idea but
we have an established idiom that has the no-arg constructor invoking
a static method that does the permission check.
-Alan
There is an alternative. The
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission(Class<?>)
checks the permission without running any code of the class.
I did look at checking the permission of the impl class, but with
service loader this would have to be done after the instance is
created, which in itself should not be a big issue here as the
provider would not be used by java.net.URL, but the side-effect is
that we end up creating an instance that will not be used.
> But if
verify-er checks constructor flow then this is as good as proposed.
I am happy that the verifier will catch this. This is an established
idiom that has been used in other, more sensitive, areas.
I'll see if I can prove this with an out-of-order compilation, or
something.
-Chris.
The idiom with constructor is also more correct from security standpoint
as all the constructors in class hierarchy are on the call-stack when
the check is made. If particular classes from the hierarchy have
separate protection domains, the check covers all of them and that's
correct since code from any or all of them could be involved in later
URL constructions.
Peter
