Hi Roman,
this issue was filed. While it's not very serious, and could at most be used
to do a dos attack on one VM - but there's plenty of other ways to do that (like
creating thousands of threads), it should still be addressed.
Java security model won't allow the client code to be run in a privileged
context, so there's no problem with the client trying to supply an object with
overridden public methods which could potentially be called from JDK code with
elevated privileges:
http://java.sun.com/javase/6/docs/technotes/guides/security/spec/security-spec.doc4.html#24646
When the checkPermission method of the AccessController is invoked by the most
recent caller (e.g., a method in the File class), the basic algorithm for
deciding whether to allow or deny the requested access is as follows.
If any caller in the call chain does not have the requested permission,
AccessControlException is thrown, unless the following is true --
a caller whose domain is granted the said permission has been marked as
"privileged" (see the next section) and all parties subsequently called by
this caller (directly or indirectly) all have the said permission.
Thanks,
Dmitri
Roman Kennke wrote:
Hi,
While looking through X11GraphicsDevice I found a potential problem. The
array returned by getConfigurations() is the real thing, and is mutable.
Client code could get the array and write crap into it (e.g. null). This
will most likely turn out to be the problem of the caller in the end,
but I'm not sure if it couldn't be used to do nasty things as well when
sneaking in manipulated GC objects. Maybe this should be made so that it
returns a copy of the real array instead?
/Roman
