RFR: 8227587: Add internal privileged System.loadLibrary
mandy.chung at oracle.com
Wed Jul 17 22:09:21 UTC 2019
On 7/17/19 3:25 AM, Claes Redestad wrote:
> Hi Peter,
> On 2019-07-17 10:29, Peter Levart wrote:
>> Hi Claes,
>> Am I reading correct that package-private
>> ClassLoader.loadLibrary(Class<?> fromClass, String name, boolean
>> isAbsolute) wouldn't need to consult SecurityManager wasn't it for
>> accessing system properties in private
>> ClassLoader.initializePath(String propName). So perhaps if the two
>> calls to initializePath() in the if block of
>> ClassLoader.loadLibrary() are wrapped with a single doPrivileged(),
>> you wouldn't have to wrap the call to JavaLangAccess.loadLibrary in
>> BootLoader. And since initializePath() would only be called once and
>> then the results cached, you end up with less doPrivileged()
>> wrappings when SecurityManager is present as soon as
>> BootLoader.loadLibrary is called the 2nd time.
> hmm, fromClass.getClassLoader() also does a security check, though.
Class::getClassLoader is caller-sensitive and the call to
fromClass.getClassLoader() does not trigger any security permission
check as it's called from NativeLibrary who is loaded by the boot loader.
> That said, there's a case for wrapping the initializePath calls in a
> doPriv of their own, since we now have an implicit requirement that some
> system library is loaded first (so that sys_paths is initialized) before
> any user code attempts to load a library of their own...
I created https://bugs.openjdk.java.net/browse/JDK-8228336 to track the
idea to refactor the system native library loading to BootLoader. I
also have JDK-8228336 capturing Peter's observation.
>> BTW, there is a data race when accessing usr_paths and sys_paths
>> static fields in multi-threaded scenario. Their type is String
>> which means that the contents of the arrays could be observed
>> uninitialized (elements being null) in some thread. Both fields
>> should be made volatile (not only sys_paths) as assignment to them
>> can be performed more than once in idempotent racy initialization.
> .. and we typically seem to be loading at least one library before
> initializing any user code, which is probably why this has never been an
> issue. It seems like a good idea to remove this subtle fragility,
> though. I wonder if we shouldn't "simply" initialize the two paths
> during bootstrap and put them in final fields.
JDK-8228336 tracks this.
More information about the core-libs-dev