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
I probably should have vetted this before hitting send... let me know if
you need any clarifications.
Cheers,
Peter.
On 23/08/2019 12:59 PM, Peter Firmstone wrote:
"...since at the time the industry believed that distributed objects
were going to save us from complexity.) Many of the sins of
"...since at the time the industry believed that distributed objects
were going to save us from complexity.) Many of the sins of
serialization were committed in the desire to get that last .1%, but the
cost and benefit of that last .1% are woefully out of balance."
The following are probably a
Hi Sean,
Regarding the section entitled "Why not write a new serialization
library?", unlike the serialization libraries listed, our purpose was to
be able to securely deserialize untrusted data, while maintaining
backward serial form compatibility with Java Serialization, provided it
didn't
Thanks Sean,
No I hadn't seen it, I've just read it, will probably need to read it
again to appreciate it fully...
It certainly identifies all the issues I'm aware of, as well as being
respectful of the original implementors (many of whom participated in
Apache River when Jini was donated to
Brian Goetz (copied) has done a lot of thinking in the serialization
area, so I have copied him. Not sure if you have seen it but he recently
posted a document about some of his ideas and possible future directions
for serialization:
http://cr.openjdk.java.net/~briangoetz/amber/serialization.ht
Thanks Sean,
You've gone to some trouble to answer my question, which demonstrates
you have considered it.
I donate some time to help maintain Apache River, derived from Sun's
Jini. Once Jini depended on RMI, today, not so much, it still has some
dependencies on some RMI interfaces, but doe
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 b
+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 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 by
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
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
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 PermissionCollection.
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 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 se
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
36 matches
Mail list logo
