Thanks for the review, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 18. September 2019 19:16
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: core-libs-dev
> Subject: Re: [11u] RFR 8229773: Resolve permissions for code
Looks ok to me!
/Claes
On 2019-09-18 12:01, Langer, Christoph wrote:
Hi,
please review the backport for JDK-8229773: Resolve permissions for code source
URLs lazily to OpenJDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~clanger/webrevs
Hi,
please review the backport for JDK-8229773: Resolve permissions for code source
URLs lazily to OpenJDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/
Original Change: https://hg.openjdk.java.net/jdk/jdk/
Hi Alan,
Your suspicion is correct. :)
Thanks for the leads, I'll look into it further.
Currently the policy implementation finds policy url's in system
properties, "java.security.policy" and numbered policy locations with
the prefix "policy.url." if the "java.security.policy" property doesn'
On 14/09/2019 21:21, Peter Firmstone wrote:
Hi Alan,
We've got a bunch of very old policy files in our test suite, so they
still had policy grants using the extension directory property. The
grant for the extension directory property was followed by a forward
slash and asterix. Oddly when t
Hi Alan,
We've got a bunch of very old policy files in our test suite, so they
still had policy grants using the extension directory property. The
grant for the extension directory property was followed by a forward
slash and asterix. Oddly when the property was missing the grant became
a w
On 13/09/2019 23:07, Peter Firmstone wrote:
:
One change I noticed is permissions granted to the java extension
directory are now granted to every domain in our policy provider as
the java.ext.dirs property is now blank, I also had to grant
permissions to a number of jdk modules, after fixing
Hi Claes,
So this security manager is part of a much larger program, (a fork of
Jini / Apache River), I've almost finished the transition from Java 8 to
Java 11...
One change I noticed is permissions granted to the java extension
directory are now granted to every domain in our policy provid
Thanks everyone. Pushed.
/Claes
Roger Riggs skrev: (16 augusti 2019 19:00:29 CEST)
>+1
>
>On 8/16/19 12:51 PM, Sean Mullan wrote:
>> +1 from me as well.
>>
>> --Sean
>>
>> On 8/16/19 12:38 PM, Alan Bateman wrote:
>>> On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
Thanks Claes,
I'll run some tests :)
Cheers,
Peter.
On 16/08/2019 9:14 PM, Claes Redestad wrote:
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things
+1
On 8/16/19 12:51 PM, Sean Mullan wrote:
+1 from me as well.
--Sean
On 8/16/19 12:38 PM, Alan Bateman wrote:
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the
jr
+1 from me as well.
--Sean
On 8/16/19 12:38 PM, Alan Bateman wrote:
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the jrt-specific
optimization is now redundant.
Lo
On 16/08/2019 13:30, Claes Redestad wrote:
How about this:
http://cr.openjdk.java.net/~redestad/8229773/webrev.03/
Also simplified BuiltinClassLoader#getPermissions since the jrt-specific
optimization is now redundant.
Looks good.
-Alan
On 2019-08-15 21:21, Alan Bateman wrote:
On 15/08/2019 16:22, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
This mostly looks good. In LazyCodeSourcePermissionCollection it think
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things stay neutral w.r.t.
Permission initialization order when using any SecurityManager. It's not
perfectly
Hello Alan,
Yes, we are aware of those issues.
I mean documenting that system Permission classes should be loaded
before setting a custom SecurityManager, accessing the file system is
important, so if you haven't loaded the necessary classes before setting
a custom SecurityManager, it won't b
On 15/08/2019 23:20, Peter Firmstone wrote:
:
The following code is included in the constructor of our
SecurityManager implementation, I suspect we may need to add some
classes to this list, perhaps this is something that needs documenting?
The checkPermission method of custom security manager
Hello Alan,
This is related to URL and CodeSource and might be worth making a note
of for future reference.
Our software uses delayed dynamically assigned permissions via a policy
provider, but for privileged domains that have AllPermission we make
sure to assign this up front (We also utili
Hello Claes,
The following code is included in the constructor of our SecurityManager
implementation, I suspect we may need to add some classes to this list,
perhaps this is something that needs documenting?
Regards,
Peter.
/* The following ensures the classes we need are loaded early to av
On 15/08/2019 16:22, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
This mostly looks good. In LazyCodeSourcePermissionCollection it think
"initialize" should be renamed to "ensureAdde
Thanks Claes,
Looks good to me too.
best regards,
-- daniel
On 15/08/2019 16:27, Roger Riggs wrote:
Looks good,
Thanks, Roger
On 8/15/19 11:22 AM, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8
Looks good,
Thanks, Roger
On 8/15/19 11:22 AM, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
/Claes
On 2019-08-15 16:54, Roger Riggs wrote:
Hi Claes,
I would recommend using wri
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
/Claes
On 2019-08-15 16:54, Roger Riggs wrote:
Hi Claes,
I would recommend using writeReplace to serialize the
PermissionCollection so the serialized form d
Hi Daniel,
seems prudent, especially if we are to writeReplace the
underlying collection on serialization.
/Claes
On 2019-08-15 17:10, Daniel Fuchs wrote:
Hi Claes,
I wonder if initialize() should check the state of
the readOnly() flag - and if that's true, call
perms.setReadOnly() ?
see Sec
Hi Claes,
I wonder if initialize() should check the state of
the readOnly() flag - and if that's true, call
perms.setReadOnly() ?
see SecureClassLoader::getProtectionDomain(..)
best regards,
-- daniel
On 15/08/2019 13:44, Claes Redestad wrote:
Hi,
On 2019-08-15 12:56, Alan Bateman wrote:
O
Hi Sean,
On 2019-08-15 15:07, Sean Mullan wrote:
Hi Claes,
I already reviewed an earlier version of this and this is pretty
similar. I did have a question about whether the default serialization
was ok - did you look into that more?
ah, yes.. all the constituents are serializable (whether w
Hi Claes,
I already reviewed an earlier version of this and this is pretty
similar. I did have a question about whether the default serialization
was ok - did you look into that more?
--Sean
On 8/15/19 6:03 AM, Claes Redestad wrote:
Hi,
by resolving permissions for code source URLs lazily,
Hi,
On 2019-08-15 12:56, Alan Bateman wrote:
On 15/08/2019 11:03, Claes Redestad wrote:
Hi,
by resolving permissions for code source URLs lazily, we can reduce
early class loading during bootstrap, which improves footprint, startup
and reduces the typical bootstrap dependency graph.
Bug: h
On 15/08/2019 11:03, Claes Redestad wrote:
Hi,
by resolving permissions for code source URLs lazily, we can reduce
early class loading during bootstrap, which improves footprint, startup
and reduces the typical bootstrap dependency graph.
Bug: https://bugs.openjdk.java.net/browse/JDK-8229773
Hi,
by resolving permissions for code source URLs lazily, we can reduce
early class loading during bootstrap, which improves footprint, startup
and reduces the typical bootstrap dependency graph.
Bug:https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~redesta
30 matches
Mail list logo