Re: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance
On Thu, 10 Jun 2021 06:59:25 GMT, Dongbo He wrote:
>> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
>> line 130:
>>
>>> 128: AlgorithmDecomposer decomposer) {
>>> 129: super(decomposer);
>>> 130: List disabledAlgorithmsList =
>>> getAlgorithms(propertyName);
>>
>> Is it doable to have the getAlgorithms() method return a Set?
>
> The collection required when new Constraints() should retain the default case
> of the elements, because some code will depend on this, for example, .
> [entry.startsWith("keySize")](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L383).
> But the set required by the permits should unify the case of the elements,
> because algorithm may be uppercase or lowercase, but the Set:contains()
> cannot handle this situation.
> So we need to create a new Set that ignores the default case of elements.
For the entry.startsWith("keySize") example, I don't think keySize is an
algorithm that could be listed individually in the list. The "keySize" may be
just a part one algorithm, for example "RSA keySize < 1024".
It's a good point about the lowercase and upper case. Did you check how
constraints like the "keySize" are expressed in the list or set?
-
PR: https://git.openjdk.java.net/jdk/pull/4424
Re: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance
On Thu, 10 Jun 2021 18:10:37 GMT, Sean Mullan wrote: > I think it would be worthwhile to see if we can take this a step further, and > leverage the `Constraint` objects that are already created and stored in the > `Constraints` object in a `HashMap>`. The key is the > algorithm `String`, and the value is a `List` of `Constraint` objects that > apply to it. If the algorithm is completely disabled, the `List` would > contain one entry `Constraint.DisabledConstraint` (which has a `permits` > method that always returns `false`). > > This way we could potentially eliminate the List/Set cache entirely and just > use the HashMap to check if the algorithm is disabled. Thanks for the suggestion, `Constraints` is a private inner class in `DisabledAlgorithmConstraints.java` and cannot be accessed in `AbstractAlgorithmConstraints.java:checkAlgorithm`. Moreover, this method does not seem to be applicable to class `LegacyAlgorithmConstraints.java`, because there is no `Constraints` object in it. - PR: https://git.openjdk.java.net/jdk/pull/4424
[jdk17] RFR: 8268349: Provide more detail in JEP 411 warning messages
More loudly and precise warning messages when a security manager is either enabled at startup or installed at runtime. This is new PR for the `openjdk/jdk17` repo copied from https://github.com/openjdk/jdk/pull/4400. A new commit is added. - Commit messages: - no cache, new warning, enhance one test, fix one test - 8268349: Provide more detail in JEP 411 warning messages Changes: https://git.openjdk.java.net/jdk17/pull/13/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=13=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268349 Stats: 105 lines in 6 files changed: 64 ins; 19 del; 22 mod Patch: https://git.openjdk.java.net/jdk17/pull/13.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/13/head:pull/13 PR: https://git.openjdk.java.net/jdk17/pull/13
Withdrawn: 8268349: Provide more detail in JEP 411 warning messages
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote: > More loudly and precise warning messages when a security manager is either > enabled at startup or installed at runtime. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4400
[jdk17] RFR: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE
The test must run with sudo but I forgot to mention it. New comment and a better error message is added. - Commit messages: - 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE Changes: https://git.openjdk.java.net/jdk17/pull/12/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=12=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268093 Stats: 14 lines in 2 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk17/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/12/head:pull/12 PR: https://git.openjdk.java.net/jdk17/pull/12
Withdrawn: 8268093: Manual Testcase: "sun/security/krb5/config/native/TestDynamicStore.java" Fails with NPE
On Mon, 7 Jun 2021 20:57:52 GMT, Weijun Wang wrote: > The test must run with sudo but I forgot to mention it. New comment and a > better error message is added. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4401
[jdk17] Integrated: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. This pull request has now been integrated. Changeset: 7b2e7d8b Author:Weijun Wang URL: https://git.openjdk.java.net/jdk17/commit/7b2e7d8bab890bd655093976cc9c3b0b6d00c034 Stats: 158 lines in 5 files changed: 52 ins; 69 del; 37 mod 8268525: Some new memory leak after JDK-8248268 and JDK-827 Reviewed-by: valeriep, ascarpino - PR: https://git.openjdk.java.net/jdk17/pull/3
Re: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 [v2]
On Thu, 10 Jun 2021 20:04:13 GMT, Weijun Wang wrote: >> Remove newly leaked memory. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > clean up one class Update looks good. - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/3
Re: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557 [v2]
> Remove newly leaked memory. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: clean up one class - Changes: - all: https://git.openjdk.java.net/jdk17/pull/3/files - new: https://git.openjdk.java.net/jdk17/pull/3/files/92375608..81d14efd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17=3=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17=3=00-01 Stats: 71 lines in 1 file changed: 7 ins; 50 del; 14 mod Patch: https://git.openjdk.java.net/jdk17/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk17/pull/3
Re: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. They look fine - Marked as reviewed by ascarpino (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/3
Re: [jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
On Thu, 10 Jun 2021 17:10:22 GMT, Weijun Wang wrote: > Remove newly leaked memory. Marked as reviewed by valeriep (Reviewer). Changes look good to me. Thanks for catching these. Valerie - PR: https://git.openjdk.java.net/jdk17/pull/3
Re: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance
On Wed, 9 Jun 2021 07:53:43 GMT, Dongbo He wrote: > Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm > has been disabled. It is less efficient when there are more disabled elements > in the list, we can use Set instead of List to speed up the search. > > Patch contains a benchmark that can be run with `make test > TEST="micro:java.security.AlgorithmConstraintsPermits"`. > Baseline results before patch: > > Benchmark(algorithm) Mode CntScore > Error Units > AlgorithmConstraintsPermits.permitsSSLv3 avgt5 21.687 ? > 1.118 ns/op > AlgorithmConstraintsPermits.permits DES avgt5 324.216 ? > 6.233 ns/op > AlgorithmConstraintsPermits.permits NULL avgt5 709.462 ? > 51.259 ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt5 687.497 ? > 170.181 ns/op > > Benchmark results after patch: > > Benchmark(algorithm) Mode CntScoreError > Units > AlgorithmConstraintsPermits.permitsSSLv3 avgt5 46.407 ? 1.057 > ns/op > AlgorithmConstraintsPermits.permits DES avgt5 65.722 ? 0.578 > ns/op > AlgorithmConstraintsPermits.permits NULL avgt5 43.988 ? 1.264 > ns/op > AlgorithmConstraintsPermits.permits TLS1.3 avgt5 399.546 ? 11.194 > ns/op > > SSLv3, DES, NULL are the first, middle and last element in > `jdk.tls.disabledAlgorithms` from `conf/security/java.security`. > > Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0 keep-alive)+Jmeter: > Before patch: > > summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min:16 Max: 1281 Err: > 0 (0.00%) > summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min:16 Max: 1281 Err: > 0 (0.00%) > summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min:16 Max: 1281 Err: > 0 (0.00%) > summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > After patch: > > summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min:26 Max: 697 Err: > 0 (0.00%) > summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min:26 Max: 697 Err: > 0 (0.00%) > summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min:26 Max: 697 Err: > 0 (0.00%) > summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256 Err: > 0 (0.00%) Active: 400 Started: 400 Finished: 0 > > > Testing: tier1, tier2 I think it would be worthwhile to see if we can take this a step further, and leverage the `Constraint` objects that are already created and stored in the `Constraints` object in a `HashMap>`. The key is the algorithm `String`, and the value is a `List` of `Constraint` objects that apply to it. If the algorithm is completely disabled, the `List` would contain one entry `Constraint.DisabledConstraint` (which has a `permits` method that always returns `false`). This way we could potentially eliminate the List/Set cache entirely and just use the HashMap to check if the algorithm is disabled. - PR: https://git.openjdk.java.net/jdk/pull/4424
[jdk17] RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
Remove newly leaked memory. - Commit messages: - 8268525: Some new memory leak after JDK-8248268 and JDK-827 Changes: https://git.openjdk.java.net/jdk17/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=3=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268525 Stats: 88 lines in 5 files changed: 45 ins; 19 del; 24 mod Patch: https://git.openjdk.java.net/jdk17/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk17/pull/3
Withdrawn: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
On Thu, 10 Jun 2021 15:40:56 GMT, Weijun Wang wrote: > Remove newly leaked memory. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/4466
RFR: 8268525: Some new memory leak after JDK-8248268 and JDK-8255557
Remove newly leaked memory. - Commit messages: - 8268525: Some new memory leak after JDK-8248268 and JDK-827 Changes: https://git.openjdk.java.net/jdk/pull/4466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4466=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268525 Stats: 88 lines in 5 files changed: 45 ins; 19 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/4466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4466/head:pull/4466 PR: https://git.openjdk.java.net/jdk/pull/4466
Re: Low level hooks in JDK for instrumentation of permission checks.
On 10/06/2021 07:40, Peter Firmstone wrote: Just a quick question, would it be possible that some JFR hooks might also be useable for an authorisation layer? JFR events can't be used to intercept/veto operations, assuming that is what you are asking. However, it might be that JFR events are monitored as part of some overall security approach that takes into account events recorded for health, performance, or troubleshooting purposes. -Alan
Re: RFR: 8268427: Improve AlgorithmConstraints:checkAlgorithm performance
On Wed, 9 Jun 2021 17:52:37 GMT, Xue-Lei Andrew Fan wrote:
>> Now AlgorithmConstraints:checkAlgorithm uses List to check if an algorithm
>> has been disabled. It is less efficient when there are more disabled
>> elements in the list, we can use Set instead of List to speed up the search.
>>
>> Patch contains a benchmark that can be run with `make test
>> TEST="micro:java.security.AlgorithmConstraintsPermits"`.
>> Baseline results before patch:
>>
>> Benchmark(algorithm) Mode CntScore
>> Error Units
>> AlgorithmConstraintsPermits.permitsSSLv3 avgt5 21.687 ?
>> 1.118 ns/op
>> AlgorithmConstraintsPermits.permits DES avgt5 324.216 ?
>> 6.233 ns/op
>> AlgorithmConstraintsPermits.permits NULL avgt5 709.462 ?
>> 51.259 ns/op
>> AlgorithmConstraintsPermits.permits TLS1.3 avgt5 687.497 ?
>> 170.181 ns/op
>>
>> Benchmark results after patch:
>>
>> Benchmark(algorithm) Mode CntScore
>> Error Units
>> AlgorithmConstraintsPermits.permitsSSLv3 avgt5 46.407 ?
>> 1.057 ns/op
>> AlgorithmConstraintsPermits.permits DES avgt5 65.722 ?
>> 0.578 ns/op
>> AlgorithmConstraintsPermits.permits NULL avgt5 43.988 ?
>> 1.264 ns/op
>> AlgorithmConstraintsPermits.permits TLS1.3 avgt5 399.546 ?
>> 11.194 ns/op
>>
>> SSLv3, DES, NULL are the first, middle and last element in
>> `jdk.tls.disabledAlgorithms` from `conf/security/java.security`.
>>
>> Tomcat(maxKeepAliveRequests=1, which will disable HTTP/1.0
>> keep-alive)+Jmeter:
>> Before patch:
>>
>> summary + 50349 in 00:00:30 = 1678.4/s Avg: 238 Min: 188 Max: 298
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 135183 in 00:01:22 = 1654.5/s Avg: 226 Min:16 Max: 1281
>> Err: 0 (0.00%)
>> summary + 50240 in 00:00:30 = 1674.1/s Avg: 238 Min: 200 Max: 308
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 185423 in 00:01:52 = 1659.7/s Avg: 229 Min:16 Max: 1281
>> Err: 0 (0.00%)
>> summary + 50351 in 00:00:30 = 1678.4/s Avg: 238 Min: 191 Max: 306
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 235774 in 00:02:22 = 1663.7/s Avg: 231 Min:16 Max: 1281
>> Err: 0 (0.00%)
>> summary + 50461 in 00:00:30 = 1681.9/s Avg: 237 Min: 174 Max: 303
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>>
>> After patch:
>>
>> summary + 59003 in 00:00:30 = 1966.6/s Avg: 203 Min: 158 Max: 272
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 146675 in 00:01:18 = 1884.6/s Avg: 198 Min:26 Max: 697
>> Err: 0 (0.00%)
>> summary + 58965 in 00:00:30 = 1965.9/s Avg: 203 Min: 166 Max: 257
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 205640 in 00:01:48 = 1907.2/s Avg: 199 Min:26 Max: 697
>> Err: 0 (0.00%)
>> summary + 59104 in 00:00:30 = 1969.1/s Avg: 203 Min: 157 Max: 266
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>> summary = 264744 in 00:02:18 = 1920.7/s Avg: 200 Min:26 Max: 697
>> Err: 0 (0.00%)
>> summary + 59323 in 00:00:30 = 1977.6/s Avg: 202 Min: 158 Max: 256
>> Err: 0 (0.00%) Active: 400 Started: 400 Finished: 0
>>
>>
>> Testing: tier1, tier2
>
> src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
> line 130:
>
>> 128: AlgorithmDecomposer decomposer) {
>> 129: super(decomposer);
>> 130: List disabledAlgorithmsList =
>> getAlgorithms(propertyName);
>
> Is it doable to have the getAlgorithms() method return a Set?
The collection required when new Constraints() should retain the default case
of the elements, because some code will depend on this, for example, .
[entry.startsWith("keySize")](https://github.com/openjdk/jdk/blob/dd1cbadc82bcecf718b96c833a5845fde79db061/src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java#L383).
But the set required by the permits should unify the case of the elements,
because algorithm may be uppercase or lowercase, but the Set:contains() cannot
handle this situation.
So we need to create a new Set that ignores the default case of elements.
-
PR: https://git.openjdk.java.net/jdk/pull/4424
Re: Low level hooks in JDK for instrumentation of permission checks.
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
Regards,
Peter.
On 9/06/2021 11:35 am, Peter Firmstone wrote:
Apologies in advance if this seems like paranoid security.
As you are likely now aware, we have been using SecurityManager a
little differently than recommended as we adapted it to our requirements.
Sometimes it's not always easy to explain or obvious why something is
done in a certain way.
It's clear we can use StackWalker to implement AccessController
functionality. And it's also clear we can use ThreadLocal or Scope
Local's to preserve the user Subject across threads.
Going forward we will need low level hooks in the JDK for our
authentication layer, clearly this is an opportunity to further
simplify and improve our authentication layer.
Because we use a remote service architecture, with proxy's, the
proxy's are dynamically granted permission's after Service
Authentication, these permissions also require the user principal to
be logged in, we may have a number of services on the stack, for
example to participate in a transaction.
We have a tool to generate least privilege policy files.
There are two reasons we do this:
1. Simplicity of administration and auditing of policy files.
2. Limit the permissions of code, and grant certain permissions to
users to ensure users are authenticated before allowing data parsing.
An example of item two, is our services require users to be logged in
to ensure that any data provided by the user is a trusted data source
(we still check the data). We re-implemented a subset of Java
Serialization and have a DeSerializationPermission, which is granted
to Principals of users.
If a user is not logged in, data cannot be de-serialized, because the
code alone doesn't have permission to do so.
Hopefully modules and packages will have strong encapsulation in
future so we don't need permission's like java.lang.RuntimePermission
"accessClassInPackage.*" No doubt we will need to create our own
Permission's.
We would like to be able to limit data parsing, like XML or Java
de-serialization, to logged in users only.
We don't break encapsulation, in future we will only use reflection to
call public methods and constructors (we are currently in the process
of doing so). Our build systems use Maven, our build is modular.
I would also like to request that all JDK modules be given
ProtectionDomain's with CodeSource's for modules with
meaningful URL's jrt:java.* or jrt:jdk.* following
SecurityManager deprecation. Currently some modules have null
ProtectionDomain's to show they have AllPermission. However we don't
grant AllPermission to code in practise, we like to grant certain
Permission's to Principal's, not code, where the Principal is the
source of data, indicating the user has been authenticated and we only
grant what's necessary and no more.
Examples of permission's granted to JDK modules in POLP policy files,
taken from a test harness:
grant codebase "jrt:/jdk.security.jgss"
{
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.security.SecurityPermission
"putProviderProperty.JdkSASL";
};
grant codebase "jrt:/jdk.crypto.mscapi"
{
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
permission java.security.SecurityPermission
"putProviderProperty.SunMSCAPI";
};
grant codebase "jrt:/jdk.localedata"
{
permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.locale.provider";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.resources";
};
grant codebase "jrt:/jdk.security.auth"
{
permission java.io.FilePermission
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar",
"read";
permission javax.security.auth.AuthPermission "modifyPrincipals";
permission javax.security.auth.AuthPermission
"modifyPrivateCredentials";
permission javax.security.auth.AuthPermission
"modifyPublicCredentials";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.krb5";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission "getProtectionDomain";
};
Example of POLP grant to code with principal, code alone cannot access
these, in case you are wondering, we use this to secure the RMI
Registry using stateless TLSv1.3, it's used by our Service Watchdog,
or Service Activation framework called Phoenix, it's the sole use we
have of the Java RMI JRMP protocol, in cases where this isn't used we
can disable Java Serialization completely:
grant codebase
"file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-rmi-tls-3.1.1-SNAPSHOT.jar",
principal
Re: Low level hooks in JDK for instrumentation of permission checks.
Thanks Alan, You've hit the nail on the head. In policy implementations, a null CodeSource in PD, is assigned AllPermission. So it would require adding grant statements for these modules in the default policy file that ships with the JVM. I thought it's an opportunity to make ProtectionDomain a little more useful if it maps to modules. Gut feel is it would be relatively low risk, but as you correctly state, would require testing. I'm not able to lodge on Jira, but I thought this would be worthy update. Regards, Peter. On 10/06/2021 4:22 pm, Alan Bateman wrote: On 10/06/2021 03:49, Peter Firmstone wrote: Hi Sean, Sorry I've confused you. What I should have said is a ProtectionDomain with a null CodeSource. What I mean to ask is, where ProtectionDomain is created with a null CodeSource, in Class::getProtectionDomain() can we have CodeSource's that represents system modules instead of null? A CodeSource with URL's like jrt:/jdk.* or jrt:/java.* for system modules? This is already the case for system modules that are mapped to the platform or application class loaders. I think your question is about modules that are mapped to the boot loader and whether they should get a unique PD that includes a useful code source rather than using a "shared" PD. That would be changing long standing behavior and would require careful analysis to see if anything would break. -Alan
Re: Low level hooks in JDK for instrumentation of permission checks.
On 10/06/2021 03:49, Peter Firmstone wrote: Hi Sean, Sorry I've confused you. What I should have said is a ProtectionDomain with a null CodeSource. What I mean to ask is, where ProtectionDomain is created with a null CodeSource, in Class::getProtectionDomain() can we have CodeSource's that represents system modules instead of null? A CodeSource with URL's like jrt:/jdk.* or jrt:/java.* for system modules? This is already the case for system modules that are mapped to the platform or application class loaders. I think your question is about modules that are mapped to the boot loader and whether they should get a unique PD that includes a useful code source rather than using a "shared" PD. That would be changing long standing behavior and would require careful analysis to see if anything would break. -Alan
