RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

[Frank Yuan]

Hi Joe and Daniel

Thank you very much for your suggestions! Now I fully understand the rule(at least I think so :P)
I will use a runWithAllPerm block surrounding the user setup code as Daniel's way. Btw, Daniel, ThreadLocal should not need Atomic
any more, correct?

Frank

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Tuesday, July 26, 2016 8:47 AM
> To: huizhe wang; Frank Yuan
> Cc: 'Amy Lu'; 'core-libs-dev'
> Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests
> 
> On 26/07/16 00:53, huizhe wang wrote:
> > To avoid having to grant the permission, the test may choose to read the
> > property before setting the SecurityManager.  You might not be able to
> > use TestNG Listeners in such case, or maybe you can by initializing the
> > properties before the test starts.
> 
> Or you can use my trick with an AtomicBoolean for such cases:
> 
> set allowAll to true
> try {
>     read system property
> } finally {
>     set allowAll to false (or to the value it had before)
> }
> 
> Adding a ThreadLocal<AtomicBoolean> allowAll to BasePolicy
> for that purpose is very easy :-)
> 
> That should ensure that you only need to give those permissions
> to the test that a regular user of the JAXP API would need to
> use the JAXP API.
> 
> If the test read/writes an XML document from file, then the
> FilePermission to read/write that document is something that
> a regular user of JAXP would need. So those permission should
> be granted to the test through Policy.
> 
> If the test reads/writes a system property or creates a directory
> or create a class loader to set up an initial configuration for
> the test to run, then this is not something a regular user of the
> JAXP API would need - so it would then be legitimate to perform this
> setup inside a block that sets allowAll to true to locally escape
> permissions checks during this setup, thus avoiding to grant those
> permissions to all in the Policy (alternatively you could use your
> tmpPermissions trick to do that as well - but it is a bit more
> complex and adds more clutter than a simple on/off switch).
> 
> cheers,
> 
> -- daniel