JEP 411: Deprecation with removal would break most existing Java libraries
Peter Firmstone
peter.firmstone at zeus.net.au
Fri Jun 18 03:24:54 UTC 2021
On 18/06/2021 1:18 pm, Peter Firmstone wrote:
>
> On 16/06/2021 11:18 pm, David Lloyd wrote:
>> On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
>> <peter.firmstone at zeus.net.au> wrote:
>>
>>> Permission references can be replaced with Guard references (which
>>> Permissions are instances of).
>> I guess you've got something fairly complex in mind, could you give
>> some practical examples of how this would work?
>
>
> The same service provider mechanism encryption uses. So
> implementation may utilize authorization access check points without
> any dependencies on current SecurityManager, Policy or Permission API's.
Eg GuardFactorySpi
>
> It's completely up to the implementation to determine how to manage.
>
>
>>
>>> The Permission implementations of Guard::check call SecurityManager, so
>>> checks will continue working as expected, but it allows us to intercept
>>> them and do something different.
>> What do you envision these checks looking like? Where would the JDK
>> find these Guard instances?
>
>
> GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET");
>
> Guard localhostConnectAccept = socketGuardFactory.orders("localhost",
> "connect,accept");
>
> // Permission check
>
> localHostConnectAccept.check();
>
>
>
> GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME");
>
> Guard createClassLoader =
> runtimeGuardFactory.orders("createClassLoader", null);
>
> // Permission check
>
> createClassLoader.check();
>
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
More information about the security-dev
mailing list