RFR JDK-8066709 Make some JDK system properties read only

[Roger Riggs]

Hi Alan,

Updated webrev in place:
http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/


On 6/4/2018 12:21 PM, Alan Bateman wrote:
> On 04/06/2018 14:32, Roger Riggs wrote:
>> Please review a change to make the values of java.home, user.home, 
>> user.dir, and user.name
>> effectively read-only for internal use.  The values are cached during 
>> initialization and the
>> cached values are used.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8066709
>>
>> CSR:
>>   https://bugs.openjdk.java.net/browse/JDK-8204235
> Can the @apiNote be split up so that the list of 4 properties moves to 
> an @implNote? Also "changing any standard property" may need 
> clarification as it can mean both changing a system property in a 
> running VM and also changing it by starting the VM with a value for 
> one of these properties.
ok, will clarify that setting the properties using setProperty or the 
getProperties().set() methods after initialization
may have unpredictable effects.

>
> I think I agree with Max on finding another name for the internal 
> class as it is a class to get the original value of a few critical 
> properties. Also I think we need to look at other ways to do the 
> initialization, maybe in conjunction with VM.saveAndRemoveProperties 
> so that we are saving the initial values of properties in one place.
There is a future, more comprehensive change that will address a more 
consistent model for system properties.
For now the task is to reduce the impact of inadvisable programmatic 
setting of standard system properties
for a few of the most (likely to be) abused properties.

>
> Are the changes to SocksSocketImpl correct? I may have missed 
> something but the original called System.getProperty("user.dir") in a 
> privileged block so I'm wondering if getUserNameChecked is needed.
The existing code in SocksSocketImpl is inconsistent with respect to 
access to user.name; some flows
use doPriv to access the property and others did not.  If someone 
familiar with the Socks networking function
can recommend the proper access, it can be revised.  The intent was to 
have the same security checks
as before.
>
> The static USER_DIR can be dropped from WindowsFileSystemProvider as 
> there is only one instance of the provider.
ok
>
> The other usages look okay to me.

Thanks, Roger

>
> -Alan
>