This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: http.agent patch
- From: Bryce McKinlay <mckinlay at redhat dot com>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: java at gcc dot gnu dot org, classpath at gnu dot org
- Date: Fri, 23 Jul 2004 11:14:31 -0400
- Subject: Re: http.agent patch
- References: <1089578898.21380.774.camel@localhost> <40F1B8C2.8070509@redhat.com> <1090582560.27014.230.camel@localhost>
[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