RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3]

[Sean Mullan]

On Fri, 25 Oct 2024 23:58:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
>> 
>> Yes I think we can remove that text.
>> 
>>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
>> 
>> You mean a warning like we have in the `Permission` subclasses?
>> 
>> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.
>
> Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.
> 
> On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

I removed the text "permissions which are retrieved by the system policy by default" from the class description and added an API note that permissions cannot be used to control access to resources. See https://github.com/openjdk/jdk/pull/21498/commits/8b527c90e434e63fd00a719aedda50d8d27e93b5

> On the other hand, I looked at its subclasses and their getPermissions(CodeSource cs) could return quite 
> complicated permission collections. I assume it does not really matter since they are all useless now, right?

Yes, although I would prefer to handle those as follow-on issues, I filed one for `URLClassLoader`: https://bugs.openjdk.org/browse/JDK-8343150

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819210679