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
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
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
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
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
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
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:
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
+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
+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.
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 8/15/19 8:18 PM, Peter Firmstone wrote:
Hi Roger,
+1 for writeReplace
Personally I'd like to see some security classes break backward
compatibility and remove support for serialization as it allows someone
to get references to internal objects, especially since these classes
are cached
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
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
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
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
Hi Roger,
+1 for writeReplace
Personally I'd like to see some security classes break backward
compatibility and remove support for serialization as it allows someone
to get references to internal objects, especially since these classes
are cached by the JVM. Which makes
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
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:
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
(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
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
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:
Hi Claes,
I would recommend using writeReplace to serialize the
PermissionCollection so the serialized form does not change.
Though these are unlikely to be serialized, it will be less likely to
trigger some interoperability issue between different version. It may
need to be documented that
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
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
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:
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:
29 matches
Mail list logo
