Re: http.agent patch

[Bryce McKinlay]

[moving this to the gcj and classpath lists]

Mark Wielaard wrote:

> On Mon, 2004-07-12 at 00:01, Bryce McKinlay wrote:
>  
>
> > > I believe the following patch addresses both
> > > concerns and makes sure that even when the Connection class is
> > > loaded/initialized from a class with not enough permissions it can still
> > > get at the necessary system properties.
> > >      
> > I wonder if we really need to use AccessController.doPrivilaged() in a 
> > static initializer. Won't the class initialization code, which calls the 
> > static initializer, already be privilaged?
> >    
>
> Yes you need that. The idea behind the whole security model is that a
> programmer needs to explicitly say whether or not they need/want only
> their own ProtectionDomain to be used with any access checks. This makes
> sure that under "normal" circumstances only security sensitive code can
> execute that the developer and the user set security manager allow to
> execute. It reliefs the developer to think about all the ways the code
> can potentially be called from an insecure environment. If you insert a
> doPrivileged() call you assert that you have thought about all ways this
> code can potentially be used from an insecure environment.
>  
Yeah.

Have a look at 
http://java.sun.com/j2se/1.4.2/docs/guide/security/doprivileged.html, 
particularly the bit about "GetPropertyAction". The syntax they suggest 
here addresses some of my concerns about PrivilagedActions. Namely, 
having a non-anonymous PrivilagedAction implementations to do common 
actions like System.getProperty() avoids the ugly anonymous class syntax 
I've seen elsewhere.

My other concern has been efficiency. Thinking about this more, the 
amount of calls that need to be privilaged is probably not as extensive 
as I first thought. Provided we follow some simple guidelines to ensure 
we are not making privilaged calls where we don't need to - for example, 
ensuring that all getProperty() calls are done only from static 
initializers, I think the overhead should be managable.

Moving forward, what we need is a list of all the calls that need to be 
privilaged - presumably this means calls that can throw 
SecurityException, and a list of all the places where they are called 
within the core classes. Does anyone have a tool that can do this? Hmm, 
maybe we can make an eclipse plugin to do it.

Regards

Bryce