On Mon, 4 Sep 2023 11:57:47 GMT, Matthias Baesken <mbaes...@openjdk.org> wrote:
>>> Hi Alan , Your assumption 'I assume the use of System.getProperty is >>> problematic when running with a SM.' is most likely correct. >> >> You'll need to test with a SM that denies reading the system property to be >> sure. There are classes in many tool APIs (you've listed some) where this >> doesn't arise. >> >> In any case, I assume this lookup will go away once you replace this method. > >> > Hi Alan , Your assumption 'I assume the use of System.getProperty is >> > problematic when running with a SM.' is most likely correct. >> >> You'll need to test with a SM that denies reading the system property to be >> sure. There are classes in many tool APIs (you've listed some) where this >> doesn't arise. >> > > For > > java.management/share/classes/sun/management/VMManagementImpl.java > > I tried with a security manager and had to grant property access so that it > worked properly. > > For > > java.desktop/share/classes/sun/awt/FontConfiguration.java > > this can be called from all code working with fonts so it needs to be handled > too (e.g. PrivilegedAction). > > Should I file a JBS issue for those two ? > > > Some of the others listed might indeed fall into the tool APIs you mentioned. @MBaesken I don't think the changes in this PR should be integrated, we shouldn't be hardcoding the values of error numbers like this. Can you think again about the suggestion to replace the Unix implementation so that it uses FileChannel/Files? That should allow you to remove the native methods for locking and chmod. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15308#issuecomment-1711197140
