Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev for the hotspot VM change a couple weeks ago [2]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.00/ While it touches many files, the fi

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: > This is the JDK change for JEP 176: JEP 176: Mechanical Checking of > Caller-Sensitive Methods [1]. Christian has posted the webrev for the > hotspot VM change a couple weeks ago [2]. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Thanks for the review. I forgot to mention that Chris contributed the initial patch (thanks). On 3/27/2013 1:13 PM, Christian Thalinger wrote: On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1].

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: > 1. I am working on a fix for 8007035 that proposes to deprecate > SecurityManager.checkMemberAccess method as it requires the caller’s frame to > be at a stack depth of four, which is fragile and difficult to enforce. Where you test c=smgr.get

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 8:01 PM, Mandy Chung wrote: > Thanks for the review. I forgot to mention that Chris contributed the > initial patch (thanks). > > On 3/27/2013 1:13 PM, Christian Thalinger wrote: >> On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: >> >>> This is the JDK change for JEP 17

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Hi Mandy the DriverManager change looks fine. Best Lance On Mar 27, 2013, at 1:35 PM, Mandy Chung wrote: > This is the JDK change for JEP 176: JEP 176: Mechanical Checking of > Caller-Sensitive Methods [1]. Christian has posted the webrev for the > hotspot VM change a couple weeks ago [2]. >

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 3/28/2013 1:54 AM, John Rose wrote: On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: 1. I am working on a fix for 8007035 that proposes to deprecate SecurityManager.checkMemberAccess method as it requires the caller’s frame to be at a stack depth of four, which is fragile and difficult t

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 27/03/2013 17:35, Mandy Chung wrote: This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev for the hotspot VM change a couple weeks ago [2]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 4/1/13 12:28 PM, Alan Bateman wrote: On 27/03/2013 17:35, Mandy Chung wrote: This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev for the hotspot VM change a couple weeks ago [2]. Webrev at: http://cr.openjdk.jav

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Mar 27, 2013, at 10:35 AM, Mandy Chung wrote: > This is the JDK change for JEP 176: JEP 176: Mechanical Checking of > Caller-Sensitive Methods [1]. Christian has posted the webrev for the > hotspot VM change a couple weeks ago [2]. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/w

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 02/04/2013 00:25, Mandy Chung wrote: These few methods are the special case that their usage are not checked. This raises a good point how we could enforce the check and whether it's appropriate to check in JVM_DoPrivileged. I will file a bug to follow up this separately if you are okay

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 4/1/13 5:24 PM, John Rose wrote: On Mar 27, 2013, at 10:35 AM, Mandy Chung > wrote: This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev for the hotspot VM change a couple weeks ago

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 04/02/2013 09:07 PM, Mandy Chung wrote: On 4/1/13 5:24 PM, John Rose wrote: On Mar 27, 2013, at 10:35 AM, Mandy Chung > wrote: This is the JDK change for JEP 176: JEP 176: Mechanical Checking of Caller-Sensitive Methods [1]. Christian has posted the webrev f

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 4/2/13 3:00 PM, Peter Levart wrote: Hi Mandy, There could be: public class SM1 extends SecurityManager { @Override public void checkMemberAccess(Class clazz, int which) {... and: public class SM2 extends SM1 { ... // no checkMemberAccess override now if if you take SM2.class.getDe

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Here is the updated webrev per John's and Alan's comments: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/ In MethodHandles.java, it calls Class.getDeclaredMethod method to determine if a SecurityManager subclass overrides checkMemberAccess. It's called only if security ma

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

So getDM has a bug and getM is correct wrt inheritance. Thanks Peter! -- John (on my iPhone) On Apr 2, 2013, at 3:25 PM, Mandy Chung wrote: > > Are you concerned the overhead of an exception thrown that we should avoid?

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On 04/03/2013 12:25 AM, Mandy Chung wrote: On 4/2/13 3:00 PM, Peter Levart wrote: Hi Mandy, There could be: public class SM1 extends SecurityManager { @Override public void checkMemberAccess(Class clazz, int which) {... and: public class SM2 extends SM1 { ... // no checkMemberAccess override

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

Peter, Thanks. I misread your example and missed the fact that SM2 extends SM1. After seeing John's reply, I reread the example and realized the correctness issue you try to point out. I'll revise it and send out a new webrev. Mandy On 4/3/2013 12:39 AM, Peter Levart wrote: On 04/03/2013

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

This version has corrected to use Class.getMethod to determine if the checkMemberAccess method is overridden in the subclass: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7198429/webrev.02/ thanks Mandy On 4/2/2013 9:25 PM, John Rose wrote: So getDM has a bug and getM is correct wrt inher

RE: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

s-dev-boun...@openjdk.java.net] on behalf of Mandy Chung [mandy.ch...@oracle.com] Sent: Wednesday, April 03, 2013 8:49 PM To: John Rose Cc: Christian Thalinger; core-libs-dev Subject: Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK This version has correc

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Apr 3, 2013, at 12:52 PM, Jeroen Frijters wrote: > Thanks for this. This is a really great change. > > I reviewed the changes and my only comment is that there is a typo in > java/lang/reflect/Field.java ("scurity"). Thanks! > Somewhat unrelated (but relevant for my implementation of Calle

RE: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

John Rose wrote: > Making Runtime and/or Runtime.load* final is an API change, which is > harder to do than an implementation change. I worry about compatibility a lot and my (selfish) reasoning is that it is better for the CCC to break someones code (there has to be someone somewhere that uses

Re: Review request for 7198429: need checked categorization of caller-sensitive methods in the JDK

On Apr 3, 2013, at 11:00 PM, Jeroen Frijters wrote: > Given the ability to create constructorless subclasses, it really should be > combined with making the class final. > > My current rules for @CallerID (which unlike @CallerSensitive is not just > about semantics, but also about implementati