From markus.knetschke at gmail.com Tue Jun 1 18:07:46 2021 From: markus.knetschke at gmail.com (Markus Knetschke) Date: Tue, 1 Jun 2021 20:07:46 +0200 Subject: j.u.c.Lock with try-with-resources In-Reply-To: References: Message-ID: Hi, I like to open a discussion about TWR support for j.u.c.Lock. There were already multiple threads about this but I think now with Valhalla & Lilliput trying to get rid of the object monitor and Loom also having problems with the monitor the incentive to use Lock is higher than ever. So I think it's again time to discuss the TWR friendliness, either through a new Lock class (which would not be my preferred way) or the extension of the Lock interface. One example I could think of would be an addition of: interface CloseableLock extends AutoCloseable { void close(); } default CloseableLock autoLock() { lock(); return this::unlock; } Implementations of this could avoid the allocation by implementing CloseableLock and returning "this" instead. This would take one pain point of not using object monitors with synchronized blocks away and get rid of the missed unlocks I sometimes see. Best regards, Markus Knetschke From brian.goetz at oracle.com Tue Jun 1 19:33:02 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Jun 2021 15:33:02 -0400 Subject: j.u.c.Lock with try-with-resources In-Reply-To: References: Message-ID: <612e5b20-fc53-46e5-0fd2-867c600bfa0c@oracle.com> This is a sad story, which gets dusted off every few years and retold. juc.ReentrantLock predates TWR, so no attempt was made to address the problem when Lock was added to the JDK. TWR came in via Project Coin, which had the effect of narrowly constraining what could be done.? TWR therefore approximates the most common case, which is a resource (e.g. file handle) on which we want to ensure cleanup.? At the time TWR came in, there was discussion about whether to retrofit ReentrantLock.? There were a range of issues, including the fact that TWR expects you to _acquire_ the resource in the TWR header, and the fact that you are not really "closing" the lock. The scheme you suggest, where the resource is not the lock but a "lock ticket", was rejected because the object allocation was deemed too expensive in the context of the critical sections that are usually guarded by locks. The new fact is that Valhalla may be able to make that ticket creation cheaper.? So this is something we could consider once Valhalla lands. On 6/1/2021 2:07 PM, Markus Knetschke wrote: > Hi, > > I like to open a discussion about TWR support for j.u.c.Lock. > There were already multiple threads about this but I think now with > Valhalla & Lilliput trying to get rid of the object monitor and Loom > also having problems with the monitor the incentive to use Lock is > higher than ever. > So I think it's again time to discuss the TWR friendliness, either > through a new Lock class (which would not be my preferred way) or the > extension of the Lock interface. > > One example I could think of would be an addition of: > interface CloseableLock extends AutoCloseable { > void close(); > } > > default CloseableLock autoLock() { > lock(); > return this::unlock; > } > > Implementations of this could avoid the allocation by implementing > CloseableLock and returning "this" instead. > > This would take one pain point of not using object monitors with > synchronized blocks away and get rid of the missed unlocks I sometimes > see. > > Best regards, > Markus Knetschke From maurizio.cimadamore at oracle.com Tue Jun 1 20:13:02 2021 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 1 Jun 2021 21:13:02 +0100 Subject: j.u.c.Lock with try-with-resources In-Reply-To: <612e5b20-fc53-46e5-0fd2-867c600bfa0c@oracle.com> References: <612e5b20-fc53-46e5-0fd2-867c600bfa0c@oracle.com> Message-ID: Hi, To add to the list - it is likely that TWR code using locks, with the scheme Brian proposes, would be like this: ``` try (LockTicket ticket = lock.acquire()) { ??? // code code code } // releases the lock ``` The body of the TWR will *not* reference the ticket at all. This is currently detected as a "misuse" of the TWR abstraction by one of javac's Lint warning ("try") - which thinks it is suspicious for a client to create a resource and then not use it. Of course changing this is not hard, once we agree on what the updgraded semantics of TWR should be - I'm just listing another possible concern (we encountered a similar issue when developing a lock-ish Panama API). Cheers Maurizio On 01/06/2021 20:33, Brian Goetz wrote: > This is a sad story, which gets dusted off every few years and retold. > > juc.ReentrantLock predates TWR, so no attempt was made to address the > problem when Lock was added to the JDK. > > TWR came in via Project Coin, which had the effect of narrowly > constraining what could be done.? TWR therefore approximates the most > common case, which is a resource (e.g. file handle) on which we want > to ensure cleanup.? At the time TWR came in, there was discussion > about whether to retrofit ReentrantLock.? There were a range of > issues, including the fact that TWR expects you to _acquire_ the > resource in the TWR header, and the fact that you are not really > "closing" the lock. > > The scheme you suggest, where the resource is not the lock but a "lock > ticket", was rejected because the object allocation was deemed too > expensive in the context of the critical sections that are usually > guarded by locks. > > The new fact is that Valhalla may be able to make that ticket creation > cheaper.? So this is something we could consider once Valhalla lands. > > On 6/1/2021 2:07 PM, Markus Knetschke wrote: >> Hi, >> >> I like to open a discussion about TWR support for j.u.c.Lock. >> There were already multiple threads about this but I think now with >> Valhalla & Lilliput trying to get rid of the object monitor and Loom >> also having problems with the monitor the incentive to use Lock is >> higher than ever. >> So I think it's again time to discuss the TWR friendliness, either >> through a new Lock class (which would not be my preferred way) or the >> extension of the Lock interface. >> >> One example I could think of would be an addition of: >> interface CloseableLock extends AutoCloseable { >> ??? void close(); >> } >> >> default CloseableLock autoLock() { >> ???? lock(); >> ???? return this::unlock; >> } >> >> Implementations of this could avoid the allocation by implementing >> CloseableLock and returning "this" instead. >> >> This would take one pain point of not using object monitors with >> synchronized blocks away and get rid of the missed unlocks I sometimes >> see. >> >> Best regards, >> Markus Knetschke > From philip.race at oracle.com Wed Jun 2 14:42:37 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 2 Jun 2021 07:42:37 -0700 Subject: Call for Discussion: Group Consolidation: Client Libraries Group Message-ID: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> I hereby propose the creation of the Client Libraries Group which is a consolidation of the interests and active members of the existing AWT [0], 2D [1], Swing [2], and Sound [3] Groups, with myself as the Lead.? I further propose the simultaneous dissolution of these historic Groups. Since at least 2015, there have been periodic discussions about whether the various OpenJDK client Groups should be consolidated.? In that time, there have been no objections so I'd like to move this proposal forward. The Client Libraries Group would be the consolidation of the existing AWT, 2D, Swing, and Sound Groups.? These individual Groups were created at the 2007 launch of OpenJDK partially following the organizational structure of Sun's existing development groups, which somewhat followed the separate nature of each of these areas. At least one Group (Sound), has always been too small an area to attract sufficient interest to justify a Group but it became one since it didn't obviously belong to another Group.? While individual Group members continue to focus in their specialization areas, there has been an increasing overlap in code responsibilities and the individuals working on them.? Some of this became apparent in the OSX port as AWT members operated as de facto members of Swing and so forth.? The distinction has been further blurred as development has moved from separate Group repository and integration practices to a single JDK-wide repository and CI model under GitHub.? Unifying these Groups will more realistically reflect the actual community and make it more apparent where sub-areas such as sound, beans, and accessibility should be discussed. The new Group will sponsor the OpenJFX [4] and Lanai [5] Projects. The long-inactive Harfbuzz [6], Framebuffer Toolkit [7] and XRender Pipeline [8] Projects will be dissolved by virtue of losing their sponsoring Group.? Over time the Group's mailing lists, static web pages, etc. will be coalesced at the discretion of the Lead. For those who don't know me I (Phil) am the OpenJDK Group Lead for the 2D and Sound Groups and the Lead of the Lanai Project. I have been a member of the Java 2D graphics team on JDK since 1999 and have contributed hundreds, if not thousands, of changes to client code over that period.? I was the specification lead for JSR 15 Image I/O Framework Specification and JSR 6 Unified Printing API.? In JDK 17, I lead JEP 382 New macOS Rendering Pipeline. The proposed set of initial members is the union of the members of the 2D, AWT, Swing, and Sound Groups who have sent mail to at least one of the five client-libs group lists (2d, awt, beans, sound, swing) or a client-libs project list (lanai) anytime since Jan 2020. ??? Alexander Scherbartiy (alexsch) ??? Alexander Zuev (kizune) ??? Alexander Zvegintsev (azvegint) ??? Alexey Ushakov (avu) ??? Jay DV (jdv) ??? Laurent Bourges (ldayne) ??? Peter Zhelezniakov (peterz) ??? Sergey Bylokhov (serb) Feedback from OpenJDK Project or Group members [9] is welcome.? If no objections are raised, or if they're raised and satisfactorily answered, by 23:59 UTC on Wesdnesday, 16 June then I will ask the OpenJDK Lead to call a Governing Board vote to simultaneously create the new Group and dissolve the AWT, 2D, Swing, and Sound Groups as described in the Bylaws [10]. -Phil. [0]: https://openjdk.java.net/census#awt [1]: https://openjdk.java.net/census#2d [2]: https://openjdk.java.net/census#swing [3]: https://openjdk.java.net/census#sound [4]: https://openjdk.java.net/census#openjfx [5]: https://openjdk.java.net/census#lanai [6]: https://openjdk.java.net/census#harfbuzz [7]: https://openjdk.java.net/census#fbtoolkit [8]: https://openjdk.java.net/census#xrender [9]: https://openjdk.java.net/census [10]: https://openjdk.java.net/bylaws#_4 From neugens.limasoftware at gmail.com Wed Jun 2 14:59:46 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 2 Jun 2021 16:59:46 +0200 Subject: Call for Discussion: Group Consolidation: Client Libraries Group In-Reply-To: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> References: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> Message-ID: <5957CDE0-D078-44DE-8B3B-A92BFC7BE19A@gmail.com> > On 2. Jun 2021, at 16:42, Philip Race wrote: > > The proposed set of initial members is the union of the members of the 2D, > AWT, Swing, and Sound Groups who have sent mail to at least one of the five > client-libs group lists (2d, awt, beans, sound, swing) or a client-libs > project list (lanai) anytime since Jan 2020. Hi Phil, Even if I?m not contributing so much lately, I would still like to be part of the initial members list for this group, if possible! Other than that, I don?t have any other feedback other than ?this is a great initiative?, so thank you for starting this process! Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ From philip.race at oracle.com Wed Jun 2 19:52:49 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 2 Jun 2021 12:52:49 -0700 Subject: Call for Discussion: Group Consolidation: Client Libraries Group In-Reply-To: <5957CDE0-D078-44DE-8B3B-A92BFC7BE19A@gmail.com> References: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> <5957CDE0-D078-44DE-8B3B-A92BFC7BE19A@gmail.com> Message-ID: <8e93d59f-1818-52ae-da3e-2eb98ce88f1f@oracle.com> Hi Mario, Thank you for your support for the proposal. Regarding initial membership I have used simple, objective criteria to *consolidate* the existing groups. In part, because of the long time that this proposal has been pondered over, it led to few new members being proposed for the existing groups. I think in fact there are several contributors who have been very and regularly active with creating fixes over the last months and year or so, that I'd like to see as members of the new group, but they aren't included here either, since I'd prefer to have no question about how the initial membership was decided, and the additional folks, such as yourself would all come in as part of group member votes, perhaps shortly after the creation of the new group - assuming the proposal is approved. -phil. On 6/2/21 7:59 AM, Mario Torre wrote: > >> On 2. Jun 2021, at 16:42, Philip Race wrote: >> >> The proposed set of initial members is the union of the members of the 2D, >> AWT, Swing, and Sound Groups who have sent mail to at least one of the five >> client-libs group lists (2d, awt, beans, sound, swing) or a client-libs >> project list (lanai) anytime since Jan 2020. > Hi Phil, > > Even if I?m not contributing so much lately, I would still like to be part of the initial members list for this group, if possible! > > Other than that, I don?t have any other feedback other than ?this is a great initiative?, so thank you for starting this process! > > Cheers, > Mario > ? > Mario Torre > Java Champion and OpenJDK contributor > > PGP Key: 0BAB254E > Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E > > Twitter: @neugens > Web: https://www.mario-torre.eu/ > Music: https://mario-torre.bandcamp.com/ > > > From neugens.limasoftware at gmail.com Thu Jun 3 13:31:20 2021 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 3 Jun 2021 15:31:20 +0200 Subject: Call for Discussion: Group Consolidation: Client Libraries Group In-Reply-To: <8e93d59f-1818-52ae-da3e-2eb98ce88f1f@oracle.com> References: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> <5957CDE0-D078-44DE-8B3B-A92BFC7BE19A@gmail.com> <8e93d59f-1818-52ae-da3e-2eb98ce88f1f@oracle.com> Message-ID: <132CE168-8078-4E4B-AD03-FC1008A4BA46@gmail.com> > On 2. Jun 2021, at 21:52, Philip Race wrote: > > Hi Mario, > > Thank you for your support for the proposal. > > Regarding initial membership I have used simple, objective criteria to *consolidate* the existing groups. > In part, because of the long time that this proposal has been pondered over, it led to few new members > being proposed for the existing groups. I think in fact there are several contributors who have been > very and regularly active with creating fixes over the last months and year or so, that I'd like > to see as members of the new group, but they aren't included here either, since I'd prefer > to have no question about how the initial membership was decided, and the additional folks, > such as yourself would all come in as part of group member votes, perhaps shortly after > the creation of the new group - assuming the proposal is approved. > > -phil. Thanks Phil, this is a very valid point! Cheers, Mario ? Mario Torre Java Champion and OpenJDK contributor PGP Key: 0BAB254E Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E Twitter: @neugens Web: https://www.mario-torre.eu/ Music: https://mario-torre.bandcamp.com/ From samuel_thomas at brown.edu Thu Jun 3 13:48:38 2021 From: samuel_thomas at brown.edu (Thomas, Samuel) Date: Thu, 3 Jun 2021 09:48:38 -0400 Subject: Detecting Hardware Threads Message-ID: Hello, I am working on a project that requires reducing the number of usable hardware threads for a benchmark that is run in the Hotspot JVM. Where in the configuration of the JVM is this determination made and where in the source should I be looking in order to make such a change? Thank you for your help! Best, Sam From shade at redhat.com Thu Jun 3 13:54:23 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Jun 2021 15:54:23 +0200 Subject: Detecting Hardware Threads In-Reply-To: References: Message-ID: <6e9c68e8-652c-35ff-3e27-6c10eda934b4@redhat.com> On 6/3/21 3:48 PM, Thomas, Samuel wrote: > I am working on a project that requires reducing the number of usable > hardware threads for a benchmark that is run in the Hotspot JVM. Where in > the configuration of the JVM is this determination made and where in the > source should I be looking in order to make such a change? Looking for -XX:ActiveProcessorCount=# option? The detection code would likely be OS-dependent, and grepping ActiveProcessorCount would get you near detection code. For example, Linux: https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L4700-L4732 -- Thanks, -Aleksey From samuel_thomas at brown.edu Thu Jun 3 14:09:18 2021 From: samuel_thomas at brown.edu (Thomas, Samuel) Date: Thu, 3 Jun 2021 10:09:18 -0400 Subject: Detecting Hardware Threads In-Reply-To: <6e9c68e8-652c-35ff-3e27-6c10eda934b4@redhat.com> References: <6e9c68e8-652c-35ff-3e27-6c10eda934b4@redhat.com> Message-ID: Great, this is what I was looking for. Thank you! On Thu, Jun 3, 2021 at 9:54 AM Aleksey Shipilev wrote: > On 6/3/21 3:48 PM, Thomas, Samuel wrote: > > I am working on a project that requires reducing the number of usable > > hardware threads for a benchmark that is run in the Hotspot JVM. Where in > > the configuration of the JVM is this determination made and where in the > > source should I be looking in order to make such a change? > > Looking for -XX:ActiveProcessorCount=# option? > > The detection code would likely be OS-dependent, and grepping > ActiveProcessorCount would get you > near detection code. For example, Linux: > > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L4700-L4732 > > -- > Thanks, > -Aleksey > > From philip.race at oracle.com Thu Jun 17 00:02:50 2021 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 Jun 2021 17:02:50 -0700 Subject: Call for Discussion: Group Consolidation: Client Libraries Group In-Reply-To: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> References: <0c5feea7-b273-4f7e-428c-bce4803bd178@oracle.com> Message-ID: The feedback period for the proposal [1] to consolidate the client groups has now ended without objections. I now request the OpenJDK Lead to call a Governing Board [2] vote on this consolidation, as described in the proposal [1]. Note, I did have a typo for the OpenJDK ID for one of the proposed initial group members. For Laurent Bourges, it should be "lbourges". -Phil. [1] https://mail.openjdk.java.net/pipermail/discuss/2021-June/005822.html [2] https://openjdk.java.net/census#gb From peter.firmstone at zeus.net.au Wed Jun 23 03:02:10 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 23 Jun 2021 13:02:10 +1000 Subject: Authorization layer API and low level access checks. Message-ID: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> Java developers such as myself need a light weight API that allows developers to continue to support authorization and access controls, without dictating how that should be implemented or whether these controls are fine grained, course grained, based solely on user authorization or also includes code authorization. SecurityManager has been deprecated, we need to commence removal of dependencies on deprecated Java API's, however we are unable to make a decision on how to proceed without understanding the level of support that OpenJDK will provide for an authorization layer in future. (If this is zero, we at least need to know). Currently there is no such API that allows developers who require an authorization layer to continue to supporting Java 8 as well future versions Java with one development codebase.? It's a non goal of this to debate the need for cross version support.?? I simply wish to open discussions on alternatives and whether OpenJDK is considering them. SecurityManager API low level functionality replacements: 1. StackWalker - Can stack walker be back ported to Java 8? 2. Permission checks - Can we have low level Guard service hooks to replace existing permission checks? Note: I'm not sure how to replace an inherited AccessControlContext (with a new implementation based on StackWalker functionality) at thread creation time, as it must be created when threads are created, possibly by using ThreadFactory everywhere, but this doesn't cover all threads.? How to cater for virtual threads? For replacement of permission checks, I propose using a Guard service authorization API (feel free to propose alternatives). The proposed authorization layer API would utilize the existing Provider Service mechanism to register authorization layer hooks, for use in permission checks by JDK code, and library code that implements their own Permission's: GuardFactory runtimeGuardFactory = GuardFactory.getInstance("RUNTIME"); Guard createClassLoader = runtimeGuardFactory.orders("createClassLoader", null); // Permission check createClassLoader.check(); Guard exitVM = runtimeGuardFactory.orders("exitVM", null); exitVM.check(); GuardFactory socketGuardFactory = GuardFactory.getInstance("SOCKET"); // Permission check socketGuardFactory.orders(host, action).check(); GuardFactory fileGuardFactory = GuardFactory.getInstance("FILE"); fileGuardFactory.orders(path, actions).check(); Guard service hooks, are based on existing Permission types (independent instances to avoid circular deadlocks), developers only need implement those relevant to them and may only use checks for users if they wish: "AWT" ?"FILE" ?"SERIALIZABLE" ?"MANAGEMENT" ?"REFLECT" ?"RUNTIME" ?"NET" ?"SOCKET" ?"URL" ?"FILE-LINK" ?"SECURITY" ?"SQL" ?"LOGGING" ?"PROPERTY" ?"MBEAN" ?"MBEAN-SERVER" ?"MBEAN-TRUST" ?"SUBJECT-DELEGATION" ?"TLS" ?"AUTH" ?"KERBEROS-DELEGATION" ?"KERBEROS-SERVICE" ?"PRIVATE-CREDENTIAL" ?"AUDIO" ?"JAXB" ?"WEB-SERVICE" I would like to suggest adding a new provider type: "PARSE-DATA" - To be called by any code about to parse data, eg deserialization, XML, JSON, SQL, etc. ? The use case for this is for servers to grant it to authenticated users (user supplied input data), so that it can only be performed following user authentication. Existing Permission implementations -- Regards, Peter Firmstone From adinn at redhat.com Wed Jun 23 09:19:42 2021 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 23 Jun 2021 10:19:42 +0100 Subject: Authorization layer API and low level access checks. In-Reply-To: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> Message-ID: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> OHi Peter, n 23/06/2021 04:02, Peter Firmstone wrote: > 1. StackWalker - Can stack walker be back ported to Java 8? The right place to ask about this is the jdk8u updates project list. However, you probably don't need to ask there because the answer is almost certainly going to be a very loud no. JDK8u is in long term maintenance mode. The goal of the updates project for that release is to fix security issues and critical bugs *and nothing else* so that existing deployments remain stable as far as possible. Except when required to meet those goals backporting of new functionality is done only under exceptional circumstances. The only recent examples of new function backports that I am aware of have involved merging up functionality from downstream releases in order to 1) unify the platform and 2) enable downstream contributors to help to maintain a single, standard release i.e. highly exceptional cases where there was a problem for existing users. Your request, by contrast, is exactly the sort of case that maintainers are trying to avoid -- it will introduce change with no gain and the potential of breakage for the vast majority of users. If you want to deal with deployments pre and post removal of the Authorization support that you currently rely on I suggest you consider doing that by using a multi-release implementation and package it using the multi-release jar format. If you don't like the idea of multi-release jars you can still implement a standard jar format solution using a provider model. However, you will still need to build the alternative provider jars using the relevant JDK releases so that different providers can rely on different JDK capabilities.. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From forax at univ-mlv.fr Wed Jun 23 10:02:14 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 23 Jun 2021 12:02:14 +0200 (CEST) Subject: Authorization layer API and low level access checks. In-Reply-To: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> Message-ID: <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Andrew Dinn" > ?: "Peter Firmstone" , "discuss" > Cc: "security-dev" > Envoy?: Mercredi 23 Juin 2021 11:19:42 > Objet: Re: Authorization layer API and low level access checks. > OHi Peter, > > n 23/06/2021 04:02, Peter Firmstone wrote: >> 1. StackWalker - Can stack walker be back ported to Java 8? > > The right place to ask about this is the jdk8u updates project list. > However, you probably don't need to ask there because the answer is > almost certainly going to be a very loud no. > > JDK8u is in long term maintenance mode. The goal of the updates project > for that release is to fix security issues and critical bugs *and > nothing else* so that existing deployments remain stable as far as > possible. Except when required to meet those goals backporting of new > functionality is done only under exceptional circumstances. > > The only recent examples of new function backports that I am aware of > have involved merging up functionality from downstream releases in order > to 1) unify the platform and 2) enable downstream contributors to help > to maintain a single, standard release i.e. highly exceptional cases > where there was a problem for existing users. Your request, by contrast, > is exactly the sort of case that maintainers are trying to avoid -- it > will introduce change with no gain and the potential of breakage for the > vast majority of users. > > If you want to deal with deployments pre and post removal of the > Authorization support that you currently rely on I suggest you consider > doing that by using a multi-release implementation and package it using > the multi-release jar format. If you don't like the idea of > multi-release jars you can still implement a standard jar format > solution using a provider model. However, you will still need to build > the alternative provider jars using the relevant JDK releases so that > different providers can rely on different JDK capabilities.. Technically, you may not need several JDKs because you can ask javac to behave as if it was compiling like a previous JDK using the option "--release" (this option is also available with Maven and Gradle). I believe that compiling as the release 8 will be supported up to Java 23. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill regards, R?mi From peter.firmstone at zeus.net.au Thu Jun 24 02:24:10 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 24 Jun 2021 12:24:10 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> Message-ID: <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> Thanks Andrew, For the simple case, of replacing the SecurityManager stack walk, one could use reflection. Thank you for also confirming that is not possible (or at least very unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK code to use a provider mechanism, to intercept permission checks, so custom authentication layers can be implemented, this could be accepted in future versions of Java, but not existing. As it is said, there is no harm in asking. The advantages of being able to address issues with Permission implementations and customise, for example,? by providing a replacement for SocketPermission, that doesn't call DNS, and allows wild cards for subnets, would be significant for the simplification of authorization. So developers might hope to be able to implement a significantly improved authorization layer for a future version of Java, provided we have some basic things like JVM hooks for access checks. -- Regards, Peter Firmstone On 23/06/2021 7:19 pm, Andrew Dinn wrote: > OHi Peter, > > n 23/06/2021 04:02, Peter Firmstone wrote: >> ?1. StackWalker - Can stack walker be back ported to Java 8? > > The right place to ask about this is the jdk8u updates project list. > However, you probably don't need to ask there because the answer is > almost certainly going to be a very loud no. > > JDK8u is in long term maintenance mode. The goal of the updates > project for that release is to fix security issues and critical bugs > *and nothing else* so that existing deployments remain stable as far > as possible. Except when required to meet those goals backporting of > new functionality is done only under exceptional circumstances. > > The only recent examples of new function backports that I am aware of > have involved merging up functionality from downstream releases in > order to 1) unify the platform and 2) enable downstream contributors > to help to maintain a single, standard release i.e. highly exceptional > cases where there was a problem for existing users. Your request, by > contrast, is exactly the sort of case that maintainers are trying to > avoid -- it will introduce change with no gain and the potential of > breakage for the vast majority of users. > > If you want to deal with? deployments pre and post removal of the > Authorization support that you currently rely on I suggest you > consider doing that by using a multi-release implementation and > package it using the multi-release jar format. If you don't like the > idea of multi-release jars you can still implement a standard jar > format solution using a provider model. However, you will still need > to build the alternative provider jars using the relevant JDK releases > so that different providers can rely on different JDK capabilities.. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From peter.firmstone at zeus.net.au Thu Jun 24 06:29:26 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 24 Jun 2021 16:29:26 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <180669749.1411843.1624442534555.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks Remi, We're still building on 8, for CORBA-IIOP stubs, but will look into this when we've found an alternative IIOP stub compiler. -- Regards, Peter On 23/06/2021 8:02 pm, Remi Forax wrote: > ----- Mail original ----- >> De: "Andrew Dinn" >> ?: "Peter Firmstone" , "discuss" >> Cc: "security-dev" >> Envoy?: Mercredi 23 Juin 2021 11:19:42 >> Objet: Re: Authorization layer API and low level access checks. >> OHi Peter, >> >> n 23/06/2021 04:02, Peter Firmstone wrote: >>> 1. StackWalker - Can stack walker be back ported to Java 8? >> The right place to ask about this is the jdk8u updates project list. >> However, you probably don't need to ask there because the answer is >> almost certainly going to be a very loud no. >> >> JDK8u is in long term maintenance mode. The goal of the updates project >> for that release is to fix security issues and critical bugs *and >> nothing else* so that existing deployments remain stable as far as >> possible. Except when required to meet those goals backporting of new >> functionality is done only under exceptional circumstances. >> >> The only recent examples of new function backports that I am aware of >> have involved merging up functionality from downstream releases in order >> to 1) unify the platform and 2) enable downstream contributors to help >> to maintain a single, standard release i.e. highly exceptional cases >> where there was a problem for existing users. Your request, by contrast, >> is exactly the sort of case that maintainers are trying to avoid -- it >> will introduce change with no gain and the potential of breakage for the >> vast majority of users. >> >> If you want to deal with deployments pre and post removal of the >> Authorization support that you currently rely on I suggest you consider >> doing that by using a multi-release implementation and package it using >> the multi-release jar format. If you don't like the idea of >> multi-release jars you can still implement a standard jar format >> solution using a provider model. However, you will still need to build >> the alternative provider jars using the relevant JDK releases so that >> different providers can rely on different JDK capabilities.. > Technically, you may not need several JDKs because you can ask javac to behave as if it was compiling like a previous JDK using the option "--release" (this option is also available with Maven and Gradle). > I believe that compiling as the release 8 will be supported up to Java 23. > >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill > regards, > R?mi From dalibor.topic at oracle.com Thu Jun 24 11:30:41 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 24 Jun 2021 13:30:41 +0200 Subject: Authorization layer API and low level access checks. In-Reply-To: <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> Message-ID: <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> On 24.06.2021 04:24, Peter Firmstone wrote: > Thanks Andrew, > > For the simple case, of replacing the SecurityManager stack walk, one > could use reflection. > > Thank you for also confirming that is not possible (or at least very > unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK code > to use a provider mechanism, to intercept permission checks, so custom > authentication layers can be implemented, this could be accepted in > future versions of Java, but not existing. As it is said, there is no > harm in asking. Generally speaking, adding any public APIs to a platform release after its specification has been published, is always going to be a very tall order involving the JCP, among other things. It's not really worth it, when other technical solutions, such as multi-release JARs, already exist, that alleviate the necessity. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From peter.firmstone at zeus.net.au Fri Jun 25 05:59:59 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 25 Jun 2021 15:59:59 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> Message-ID: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> Thanks Dalibor, Would targeting Java 18 be practical? Also it won't take long to code a prototype, just not sure of the process. Cheers, Peter. On 24/06/2021 9:30 pm, Dalibor Topic wrote: > On 24.06.2021 04:24, Peter Firmstone wrote: >> Thanks Andrew, >> >> For the simple case, of replacing the SecurityManager stack walk, one >> could use reflection. >> >> Thank you for also confirming that is not possible (or at least very >> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK >> code to use a provider mechanism, to intercept permission checks, so >> custom authentication layers can be implemented, this could be >> accepted in future versions of Java, but not existing. As it is said, >> there is no harm in asking. > > Generally speaking, adding any public APIs to a platform release after > its specification has been published, is always going to be a very > tall order involving the JCP, among other things. It's not really > worth it, when other technical solutions, such as multi-release JARs, > already exist, that alleviate the necessity. > > cheers, > dalibor topic > From peter.firmstone at zeus.net.au Sat Jun 26 02:58:48 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 26 Jun 2021 12:58:48 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> Message-ID: <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au> Summary of Proposed Changes: 1. GuardFactory & GuardFactorySpi to provide hooks for authorization checks without SecurityManager or Policy. (Note GuardFactory should never return null and instead return a no-op Guard that hotspot can optimize out. 2. Existing Permission implementations to be obtained using GuardFactorySpi implementations, until their removal.? Note that when SecurityManager is stubbed out and Permission implementations are deprecated for removal, these should no longer be provided by default, but instead need to be enabled by entries in the java.security config file, in preparation for their removal. 3. JDK code, no longer call Permission implementations directly, instances obtained using GuardFactory, only when enabled in the java.security configuration file. 4. Threads (system and virtual) updated to use a singleton *unprivileged* AccessControlContext, instead of inherited AccessControlContext, this is more appropriate for Executors, the original inherited context was designed before Executors were introduced. 5. Deprecation for removal of all Permission implementations from the JDK platform.?? The existing implementations of Permission introduce unnecessary complexity; they lack sufficient flexibility resulting in a proliferation of Permission grants required in policy files and some make blocking network calls. 6. Introduce a system property to change AccessController default behaviour, disable the stack walk by default, but allow it to be re-enabled with a system property, replace the stack walk array result of ProtectionDomains with an *unprivileged* AccessControlContext, the SubjectDomainCombiner can replace it with a, AccessControlContext containing a single element array, containing one ProtectionDomain with Principals. 7. AccessController::doPrivileged erases the DomainCombiner by default, deprecate these methods, retain doPrivilegedWithCombiner methods that preserve the SubjectDomainCombiner.?? Developers should replace their doPrivileged methods with doPrivilegedWithCombiner 8. Deprecate for removal the CodeSource::implies method. 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java modules mapped to the boot loader, rather than using a Shared ProtectionDomain with a null CodeSource. To clarify what an *unprivileged* AccessControlContext is: An instance of AccessControlContext, that contains a single element array, containing a ProtectionDomain, with a non null CodeSource, containing a null URL. Retention of AccessController, AccessControlContext, DomainCombiner and SubjectDomainCombiner and Subject::doAs methods. Stubbing of SecurityManager and Policy, for runtime backward compatibility. Update ProtectionDomain::implies method, to *not* consult with the Policy.? Note it's possible to get access to the ProtectionDomain array contained within AccessControlContext using a DomainCombiner. This is backward compatible with existing usages of JAAS and least painful method of transition for all concerned as well as allowing complete flexibility of implementation. Regards, Peter Firmstone. On 25/06/2021 3:59 pm, Peter Firmstone wrote: > Thanks Dalibor, > > Would targeting Java 18 be practical? > > Also it won't take long to code a prototype, just not sure of the > process. > > Cheers, > > Peter. > > > On 24/06/2021 9:30 pm, Dalibor Topic wrote: >> On 24.06.2021 04:24, Peter Firmstone wrote: >>> Thanks Andrew, >>> >>> For the simple case, of replacing the SecurityManager stack walk, >>> one could use reflection. >>> >>> Thank you for also confirming that is not possible (or at least very >>> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK >>> code to use a provider mechanism, to intercept permission checks, so >>> custom authentication layers can be implemented, this could be >>> accepted in future versions of Java, but not existing. As it is >>> said, there is no harm in asking. >> >> Generally speaking, adding any public APIs to a platform release >> after its specification has been published, is always going to be a >> very tall order involving the JCP, among other things. It's not >> really worth it, when other technical solutions, such as >> multi-release JARs, already exist, that alleviate the necessity. >> >> cheers, >> dalibor topic >> From peter.firmstone at zeus.net.au Sat Jun 26 03:11:18 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 26 Jun 2021 13:11:18 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au> Message-ID: One more proposed change inline: On 26/06/2021 12:58 pm, Peter Firmstone wrote: > > Summary of Proposed Changes: > > 1. GuardFactory & GuardFactorySpi to provide hooks for authorization > checks without SecurityManager or Policy. (Note GuardFactory > should never return null and instead return a no-op Guard that > hotspot can optimize out. > 2. Existing Permission implementations to be obtained using > GuardFactorySpi implementations, until their removal.? Note that > when SecurityManager is stubbed out and Permission implementations > are deprecated for removal, these should no longer be provided by > default, but instead need to be enabled by entries in the > java.security config file, in preparation for their removal. > 3. JDK code, no longer call Permission implementations directly, > instances obtained using GuardFactory, only when enabled in the > java.security configuration file. > 4. Threads (system and virtual) updated to use a singleton > *unprivileged* AccessControlContext, instead of inherited > AccessControlContext, this is more appropriate for Executors, the > original inherited context was designed before Executors were > introduced. > 5. Deprecation for removal of all Permission implementations from the > JDK platform.?? The existing implementations of Permission > introduce unnecessary complexity; they lack sufficient flexibility > resulting in a proliferation of Permission grants required in > policy files and some make blocking network calls. > 6. Introduce a system property to change AccessController default > behaviour, disable the stack walk by default, but allow it to be > re-enabled with a system property, replace the stack walk array > result of ProtectionDomains with an *unprivileged* > AccessControlContext, the SubjectDomainCombiner can replace it > with a, AccessControlContext containing a single element array, > containing one ProtectionDomain with Principals. > 7. AccessController::doPrivileged erases the DomainCombiner by > default, deprecate these methods, retain doPrivilegedWithCombiner > methods that preserve the SubjectDomainCombiner.?? Developers > should replace their doPrivileged methods with > doPrivilegedWithCombiner > 8. Deprecate for removal the CodeSource::implies method. > 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java > modules mapped to the boot loader, rather than using a Shared > ProtectionDomain with a null CodeSource. > ??? 10. Deprecate for removal AccessController::checkPermission and AccessControlContext::checkPermission methods. ??? 11. Undeprecate AccessController, AccessControlContext, DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while deprecating for removal methods stated in items above. > To clarify what an *unprivileged* AccessControlContext is: > > An instance of AccessControlContext, that contains a single > element array, containing a ProtectionDomain, with a non null > CodeSource, containing a null URL. > > Retention of AccessController, AccessControlContext, DomainCombiner > and SubjectDomainCombiner and Subject::doAs methods. > > Stubbing of SecurityManager and Policy, for runtime backward > compatibility. Update ProtectionDomain::implies method, to *not* > consult with the Policy.? Note it's possible to get access to the > ProtectionDomain array contained within AccessControlContext using a > DomainCombiner. > > This is backward compatible with existing usages of JAAS and least > painful method of transition for all concerned as well as allowing > complete flexibility of implementation. > > Regards, > > Peter Firmstone. > > On 25/06/2021 3:59 pm, Peter Firmstone wrote: >> Thanks Dalibor, >> >> Would targeting Java 18 be practical? >> >> Also it won't take long to code a prototype, just not sure of the >> process. >> >> Cheers, >> >> Peter. >> >> >> On 24/06/2021 9:30 pm, Dalibor Topic wrote: >>> On 24.06.2021 04:24, Peter Firmstone wrote: >>>> Thanks Andrew, >>>> >>>> For the simple case, of replacing the SecurityManager stack walk, >>>> one could use reflection. >>>> >>>> Thank you for also confirming that is not possible (or at least >>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is for >>>> JDK code to use a provider mechanism, to intercept permission >>>> checks, so custom authentication layers can be implemented, this >>>> could be accepted in future versions of Java, but not existing. As >>>> it is said, there is no harm in asking. >>> >>> Generally speaking, adding any public APIs to a platform release >>> after its specification has been published, is always going to be a >>> very tall order involving the JCP, among other things. It's not >>> really worth it, when other technical solutions, such as >>> multi-release JARs, already exist, that alleviate the necessity. >>> >>> cheers, >>> dalibor topic >>> -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sat Jun 26 03:46:25 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 26 Jun 2021 13:46:25 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <9084f553-7440-de48-2e03-2447ebd280c5@zeus.net.au> Message-ID: Inline below. On 26/06/2021 1:11 pm, Peter Firmstone wrote: > > One more proposed change inline: > > On 26/06/2021 12:58 pm, Peter Firmstone wrote: >> >> Summary of Proposed Changes: >> >> 1. GuardFactory & GuardFactorySpi to provide hooks for authorization >> checks without SecurityManager or Policy. (Note GuardFactory >> should never return null and instead return a no-op Guard that >> hotspot can optimize out. >> 2. Existing Permission implementations to be obtained using >> GuardFactorySpi implementations, until their removal.? Note that >> when SecurityManager is stubbed out and Permission >> implementations are deprecated for removal, these should no >> longer be provided by default, but instead need to be enabled by >> entries in the java.security config file, in preparation for >> their removal. >> 3. JDK code, no longer call Permission implementations directly, >> instances obtained using GuardFactory, only when enabled in the >> java.security configuration file. >> 4. Threads (system and virtual) updated to use a singleton >> *unprivileged* AccessControlContext, instead of inherited >> AccessControlContext, this is more appropriate for Executors, the >> original inherited context was designed before Executors were >> introduced. >> 5. Deprecation for removal of all Permission implementations from >> the JDK platform.?? The existing implementations of Permission >> introduce unnecessary complexity; they lack sufficient >> flexibility resulting in a proliferation of Permission grants >> required in policy files and some make blocking network calls. >> 6. Introduce a system property to change AccessController default >> behaviour, disable the stack walk by default, but allow it to be >> re-enabled with a system property, replace the stack walk array >> result of ProtectionDomains with an *unprivileged* >> AccessControlContext, the SubjectDomainCombiner can replace it >> with a, AccessControlContext containing a single element array, >> containing one ProtectionDomain with Principals. >> 7. AccessController::doPrivileged erases the DomainCombiner by >> default, deprecate these methods, retain doPrivilegedWithCombiner >> methods that preserve the SubjectDomainCombiner.?? Developers >> should replace their doPrivileged methods with >> doPrivilegedWithCombiner >> Just thinking out loud, it's possible someone might want to do perform some task without privileges enabled, that is without the Subject's principal's.?? In a system that grants privileges to code and principals, this is generally unnecessary, as grants are made to the combination of code and principals.? However while using the doPrivileged methods is possible, to remove privileges, it would be better to provide an AccessController::doUnprivileged method instead, which erase the DomainCombiner and use an *unprivileged* AccessControlContext. Since the doPrivileged methods are utilised by other methods in AccessController, they should be made private when finally deprecated for removal. I have also just noticed a bug in AccessController.AccHolder.innocuousAcc. The innocuous AccessControlContext, is intended to have no permission, hence it is constructed using the two argument ProtectionDomain constructor, which causes ProtectionDomain to not consult the Policy. However, if a user obtains this ProtectionDomain and asks the Policy for the ProtectionDomain's permission's by calling Policy::getPermissions(ProtectionDomain), the Policy will return AllPermission. It is generally understood that a ProtectionDomain with a null CodeSource is a system ProtectionDomain loaded by the bootstrap ClassLoader. I propose that innocuous AccessControlContext instead be given a ProtectionDomain, with a non-null CodeSource, which has a null URL.? This is also considered by the Policy to be unprivileged. >> 1. Deprecate for removal the CodeSource::implies method. >> 2. Give unique ProtectionDomain's with a meaninful CodeSource to >> Java modules mapped to the boot loader, rather than using a >> Shared ProtectionDomain with a null CodeSource. >> > ??? 10. Deprecate for removal AccessController::checkPermission and > AccessControlContext::checkPermission methods. > > ??? 11. Undeprecate AccessController, AccessControlContext, > DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while > deprecating for removal methods stated in items above. > >> To clarify what an *unprivileged* AccessControlContext is: >> >> An instance of AccessControlContext, that contains a single >> element array, containing a ProtectionDomain, with a non null >> CodeSource, containing a null URL. >> >> Retention of AccessController, AccessControlContext, DomainCombiner >> and SubjectDomainCombiner and Subject::doAs methods. >> >> Stubbing of SecurityManager and Policy, for runtime backward >> compatibility. Update ProtectionDomain::implies method, to *not* >> consult with the Policy.? Note it's possible to get access to the >> ProtectionDomain array contained within AccessControlContext using a >> DomainCombiner. >> >> This is backward compatible with existing usages of JAAS and least >> painful method of transition for all concerned as well as allowing >> complete flexibility of implementation. >> >> Regards, >> >> Peter Firmstone. >> >> On 25/06/2021 3:59 pm, Peter Firmstone wrote: >>> Thanks Dalibor, >>> >>> Would targeting Java 18 be practical? >>> >>> Also it won't take long to code a prototype, just not sure of the >>> process. >>> >>> Cheers, >>> >>> Peter. >>> >>> >>> On 24/06/2021 9:30 pm, Dalibor Topic wrote: >>>> On 24.06.2021 04:24, Peter Firmstone wrote: >>>>> Thanks Andrew, >>>>> >>>>> For the simple case, of replacing the SecurityManager stack walk, >>>>> one could use reflection. >>>>> >>>>> Thank you for also confirming that is not possible (or at least >>>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is >>>>> for JDK code to use a provider mechanism, to intercept permission >>>>> checks, so custom authentication layers can be implemented, this >>>>> could be accepted in future versions of Java, but not existing. As >>>>> it is said, there is no harm in asking. >>>> >>>> Generally speaking, adding any public APIs to a platform release >>>> after its specification has been published, is always going to be a >>>> very tall order involving the JCP, among other things. It's not >>>> really worth it, when other technical solutions, such as >>>> multi-release JARs, already exist, that alleviate the necessity. >>>> >>>> cheers, >>>> dalibor topic >>>> > -- > Regards, > > Peter Firmstone > 0498 286 363 > Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Sat Jun 26 05:41:59 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 26 Jun 2021 15:41:59 +1000 Subject: READ 1ST: Re: Authorization layer API and low level access checks In-Reply-To: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> Message-ID: Apologies for multiple earlier emails, please ignore and read this instead. This proposal is about stripping out and simplifying as much of the dilapidated and complex SecurityManager infrastructure as possible, while retaining the ability for developers to implement a better high scaling and performant Authorization layer, without prohibitively preventing it. Summary of Proposed Changes: 1. GuardFactory & GuardFactorySpi to provide hooks for authorization checks without SecurityManager or Policy. (Note GuardFactory should never return null and instead return a no-op Guard that hotspot can optimize out. 2. Existing Permission implementations to be obtained using GuardFactorySpi implementations, until their removal.? Note that when SecurityManager is stubbed out and Permission implementations are deprecated for removal, these should no longer be provided by default, but instead need to be enabled by entries in the java.security config file, in preparation for their removal. 3. JDK code to no longer call Permission implementations directly, instances obtained using GuardFactory, when enabled in the java.security configuration file. 4. Threads (system and virtual) updated to use a singleton *unprivileged* AccessControlContext, instead of inherited AccessControlContext, this is more appropriate for Executors, the original inherited context was designed before Executors were introduced. 5. Deprecation for removal of all Permission implementations from the JDK platform.?? The existing implementations of Permission introduce unnecessary complexity; they lack sufficient flexibility resulting in a proliferation of Permission grants required in policy files and some make blocking network calls. 6. Introduce a system property to change AccessController's default behaviour, disable the stack walk by default, but allow it to be re-enabled with a system property, replace the stack walk array result of ProtectionDomains with an *unprivileged* AccessControlContext, the SubjectDomainCombiner can replace it with a, AccessControlContext containing a single element array, containing one ProtectionDomain with Principals. 7. AccessController::doPrivileged erases the DomainCombiner by default, deprecate these methods for removal (make private), retain doPrivilegedWithCombiner methods that preserve the SubjectDomainCombiner.?? Developers should replace their doPrivileged methods with doPrivilegedWithCombiner.?? Create a new method AccessController::doUnprivileged, clear intent, to erase the DomainCombiner, and use the *unprivileged* AccessControlContext.? Update AccessController.AccHolder.innocuousAcc to refer to an *unprivileged* context, as per the definition below. 8. Deprecate for removal the CodeSource::implies method. 9. Give unique ProtectionDomain's with a meaninful CodeSource to Java modules mapped to the boot loader, rather than using a Shared ProtectionDomain with a null CodeSource. 10. Deprecate for removal AccessController::checkPermission and AccessControlContext::checkPermission methods. 11. Undeprecate AccessController, AccessControlContext, DomainCombiner, SubjectDomainCombiner and Subject::doAs methods, while deprecating for removal methods stated in items above. 12. Deprecate for removal ProtectionDomain::implies, ProtectionDomain::getPermissions and ProtectionDomain::staticPermissionsOnly 13. Replace PermissionCollection type argument with Object in ProtectionDomain constructors, ignore the permissions parameter, and deprecate existing constructors.?? Deprecate PermissionCollection for removal. 14. Create a new constructor: ProtectionDomain(CodeSource cs, ClassLoader cl, Principal[] p). 15. Create a new factory method ProtectionDomain::newInstance(Principal[] p), to allow a weak cache of ProtectionDomain instances for each Principal[], to be utilised by SubjectDomainCombiner to avoid unnecessary duplication of objects.?? This is an optimization for AccessControlContext::equals and ::hashCode methods.?? Using a cache of AccessControlContext, it is possible to avoid rechecking authorization that has already been checked.? For example, when using an Executor with many tasks, all with the same AccessControlContext, you only need to check once and return the same result for subsequent checks.?? This is an optimization I have used previously to great effect. To clarify what an *unprivileged* AccessControlContext is: An instance of AccessControlContext, that contains a single element array, containing a ProtectionDomain, with a null ClassLoader, null Principal[] and a *non-null* CodeSource, containing a null URL. So as to distinguish between what is traditionally a JDK bootstrap ProtectionDomain and unprivileged domain after ProtectionDomain::getPermissions is removed. Stubbing of SecurityManager and Policy, for runtime backward compatibility. Update ProtectionDomain::implies method, to *not* consult with the Policy.? Note it's possible to get access to the ProtectionDomain array contained within AccessControlContext using a DomainCombiner. This is backward compatible with existing usages of JAAS and least painful method of transition for all concerned as well as allowing complete flexibility of implementation. Regards, Peter Firmstone. On 25/06/2021 3:59 pm, Peter Firmstone wrote: > Thanks Dalibor, > > Would targeting Java 18 be practical? > > Also it won't take long to code a prototype, just not sure of the > process. > > Cheers, > > Peter. > > > On 24/06/2021 9:30 pm, Dalibor Topic wrote: >> On 24.06.2021 04:24, Peter Firmstone wrote: >>> Thanks Andrew, >>> >>> For the simple case, of replacing the SecurityManager stack walk, >>> one could use reflection. >>> >>> Thank you for also confirming that is not possible (or at least very >>> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK >>> code to use a provider mechanism, to intercept permission checks, so >>> custom authentication layers can be implemented, this could be >>> accepted in future versions of Java, but not existing. As it is >>> said, there is no harm in asking. >> >> Generally speaking, adding any public APIs to a platform release >> after its specification has been published, is always going to be a >> very tall order involving the JCP, among other things. It's not >> really worth it, when other technical solutions, such as >> multi-release JARs, already exist, that alleviate the necessity. >> >> cheers, >> dalibor topic >> From dalibor.topic at oracle.com Mon Jun 28 16:53:27 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 28 Jun 2021 18:53:27 +0200 Subject: Authorization layer API and low level access checks. In-Reply-To: <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> Message-ID: Hi Peter, Larger changes, such as those that appear to be proposed here, should come with their own JEP. Please see https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html for details. JEPs help among other things build consensus around ideas. Typically it takes around 6 months from the inception of a release, until the feature set is complete, so that should give you some sense of the timings involved. It can also be useful to split larger proposed changes into several conceptually distinguished smaller ones, and to build up consensus gradually that way. cheers, dalibor topic On 25.06.2021 07:59, Peter Firmstone wrote: > Thanks Dalibor, > > Would targeting Java 18 be practical? > > Also it won't take long to code a prototype, just not sure of the process. > > Cheers, > > Peter. > > > On 24/06/2021 9:30 pm, Dalibor Topic wrote: >> On 24.06.2021 04:24, Peter Firmstone wrote: >>> Thanks Andrew, >>> >>> For the simple case, of replacing the SecurityManager stack walk, one >>> could use reflection. >>> >>> Thank you for also confirming that is not possible (or at least very >>> unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK >>> code to use a provider mechanism, to intercept permission checks, so >>> custom authentication layers can be implemented, this could be >>> accepted in future versions of Java, but not existing. As it is said, >>> there is no harm in asking. >> >> Generally speaking, adding any public APIs to a platform release after >> its specification has been published, is always going to be a very >> tall order involving the JCP, among other things. It's not really >> worth it, when other technical solutions, such as multi-release JARs, >> already exist, that alleviate the necessity. >> >> cheers, >> dalibor topic >> -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From peter.firmstone at zeus.net.au Mon Jun 28 22:44:28 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 29 Jun 2021 08:44:28 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> Message-ID: <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> Thanks Dalibor, I'm not a committer, quite happy to do the work, but I need a sponsor. I'm currently playing around with a simpler security model, where one must escalate privileges with a privilegedCall, designed to be submitted to an Executor, which is task / thread confined. Outside of the privilegedCall, there is no stack walk, because there are no privileges, so it is unnecessary, it is represented by a singleton unprivileged domain. At the time the task is decorated with privileges, the caller that does so, has its domain recorded, at the time the task is executed, the context and Subject are reachable from a ThreadLocal, the stack walk is only performed back to the commencement of the task, the Subject and domains collected are then available to Guard's to check whether the privileged call is authorized to proceed.? The ThreadLocal context is reset back to its previous value, by a finally block, when the call returns. So basically, when you want to make a secure connection, authenticate, access files or network, you need to make a privileged call and submit it to an executor, or virtual thread, at least that's the current concept. There is no complexity such as static and dynamic Permissions, or whether the Subject is preserved or not, the Subject is always preserved in the context, which can be stored for use in other privilegedCall's, where it will be combined with the results of the task limited stack walk. The complexity of Permission's is removed, Guard providers may use whatever rule based system they desire, coarse grained, or fine grained, the information required to make the decision is available to the guard, via an Authorization class. By default, it would probably be best to provide simple coarse grained Guard providers, such that the system could be enabled and used by default, after a transition period. Cheers, Peter. On 29/06/2021 2:53 am, Dalibor Topic wrote: > Hi Peter, > > Larger changes, such as those that appear to be proposed here, should > come with their own JEP. Please see > https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html for details. > > JEPs help among other things build consensus around ideas. Typically > it takes around 6 months from the inception of a release, until the > feature set is complete, so that should give you some sense of the > timings involved. > > It can also be useful to split larger proposed changes into several > conceptually distinguished smaller ones, and to build up consensus > gradually that way. > > cheers, > dalibor topic > > On 25.06.2021 07:59, Peter Firmstone wrote: >> Thanks Dalibor, >> >> Would targeting Java 18 be practical? >> >> Also it won't take long to code a prototype, just not sure of the >> process. >> >> Cheers, >> >> Peter. >> >> >> On 24/06/2021 9:30 pm, Dalibor Topic wrote: >>> On 24.06.2021 04:24, Peter Firmstone wrote: >>>> Thanks Andrew, >>>> >>>> For the simple case, of replacing the SecurityManager stack walk, >>>> one could use reflection. >>>> >>>> Thank you for also confirming that is not possible (or at least >>>> very unlikely) to add a GuardBuilder to Java 8, the proposal is for >>>> JDK code to use a provider mechanism, to intercept permission >>>> checks, so custom authentication layers can be implemented, this >>>> could be accepted in future versions of Java, but not existing. As >>>> it is said, there is no harm in asking. >>> >>> Generally speaking, adding any public APIs to a platform release >>> after its specification has been published, is always going to be a >>> very tall order involving the JCP, among other things. It's not >>> really worth it, when other technical solutions, such as >>> multi-release JARs, already exist, that alleviate the necessity. >>> >>> cheers, >>> dalibor topic >>> > From daniel.latremoliere at gmail.com Tue Jun 29 18:42:22 2021 From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=) Date: Tue, 29 Jun 2021 20:42:22 +0200 Subject: Authorization layer API and low level access checks. In-Reply-To: <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> Message-ID: <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com> Hello, Just for my knowledge, and if I understand your need to enforce a security policy on code potentially untrusted. Isn't it possible to simply create a Java agent instrumenting bytecode [1], which will replace [2] each Java method invocation, in untrusted bytecode, which is returning a potentially sensitive object [3], by a call to a generated adapter. In the generated adapter, you can add all useful code to validate if corresponding code is allowed to see this object, potentially sensitive. A Java agent, would be compatible with all Java versions and I think it would be possible to add exactly the permissions needed. Thanks, Daniel. [1]: https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/ClassFileTransformer.html [2]: Bytecode transformation, by example with ASM: https://stackoverflow.com/a/35635682 [3]: By example, proxying each constructor or method returning an instance of class like java.io.File and java.nio.file.Path (if you want to do something like FilePermission). Le 29/06/2021 ? 00:44, Peter Firmstone a ?crit?: > I'm currently playing around with a simpler security model, where one > must escalate privileges with a privilegedCall, designed to be > submitted to an Executor, which is task / thread confined. > From peter.firmstone at zeus.net.au Wed Jun 30 00:45:40 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 30 Jun 2021 10:45:40 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com> References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com> Message-ID: Hi Daniel, That is the current intent, however identifying all methods which require protecting isn't a simple process and will change with each release. The simplest part is determining whether the combination of User and domains calling have the necessary privileges (my current focus), the difficulty is in determining the methods that require protection for which Agents must be written.? It would be nice if OpenJDK could create check points through which security sensitive objects are passed and ensure these checkpoints are always used for passing references for those types of objects, so that any new JVM code also uses these methods, so that it would be easier to control and limit the number of locations for which we need to write agents, or other mechanisms, such as provider interfaces. Otherwise there is a lot of work involved in auditing every JVM release for new code, which has the potential to pass security sensitive object references. It is not advisable to run untrusted code, the JDK doesn't adequately defend against untrusted code execution, eg memory consumption, throwing Errors, spawning Threads, the intent is to capture the privileged execution paths of software's intended functionality, using integration tests, recording and constraining the software by preventing other unintended privileged execution paths from being executed. A use case for this is restricting (narrowing the audit scope) parsing of data to the combination of audited code in a server with authenticated client subjects.? The authenticated subject, represents the source of the data, so if there's no authenticated client subject, then we don't grant the privilege to avoid parsing of untrusted data, but in addition to that, we want to also constrain parsing to a particular domain / scope, which has been audited and approved for parsing authenticated user data.??? While we trust other libraries utilised to generally do the right thing, it isn't practical to audit all code that might also be capable of parsing data that we don't intend to utilise, so we don't grant those libraries privileges they are not required to have, in accordance with principles of least privilege. The intent is simply to limit scope to make security auditing practical and affordable.?? Java has a very large ecosystem, so it isn't practical to audit everything.? We also want authorization to be simpler to deploy and less complex to utilize. Regards, Peter. On 30/06/2021 4:42 am, Daniel Latr?moli?re wrote: > Hello, > > Just for my knowledge, and if I understand your need to enforce a > security policy on code potentially untrusted. > > Isn't it possible to simply create a Java agent instrumenting bytecode > [1], which will replace [2] each Java method invocation, in untrusted > bytecode, which is returning a potentially sensitive object [3], by a > call to a generated adapter. > > In the generated adapter, you can add all useful code to validate if > corresponding code is allowed to see this object, potentially sensitive. > > A Java agent, would be compatible with all Java versions and I think > it would be possible to add exactly the permissions needed. > > Thanks, > > Daniel. > > [1]: > https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/ClassFileTransformer.html > > [2]: Bytecode transformation, by example with ASM: > https://stackoverflow.com/a/35635682 > > [3]: By example, proxying each constructor or method returning an > instance of class like java.io.File and java.nio.file.Path (if you > want to do something like FilePermission). > > > > Le 29/06/2021 ? 00:44, Peter Firmstone a ?crit?: >> I'm currently playing around with a simpler security model, where one >> must escalate privileges with a privilegedCall, designed to be >> submitted to an Executor, which is task / thread confined. >> -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. From peter.firmstone at zeus.net.au Wed Jun 30 11:38:06 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 30 Jun 2021 21:38:06 +1000 Subject: Authorization layer API and low level access checks. In-Reply-To: References: <896e5ba9-fee6-1aca-3efa-dc2e6e8fb61e@zeus.net.au> <265e217d-6e98-1916-3584-b17844dbc7c2@redhat.com> <5176c40c-56cb-85da-6e96-9a237a783fdc@zeus.net.au> <6523763c-a3ee-07a9-de55-103c5d790a5b@oracle.com> <2f315680-1cdb-1694-34a3-95312bf42ca7@zeus.net.au> <23b99a92-d29e-38c5-5b0d-e2cb70d99c45@zeus.net.au> <9f6d70c1-f073-482d-cf46-c354ad3c902e@gmail.com> Message-ID: <974bd92d-4a7b-a454-af54-8b395e411abc@zeus.net.au> A draft Authorization implementation, untested. -- Regards, Peter Firmstone /** ?* Authorization class, instances contain the domains and Subject of the ?* Authorization context, used for Authorization decisions by Guard ?* implementations.? Provides static utility methods to make privilgedCall's ?* and record the current context. ?* ?* @author peter ?*/ public final class Authorization { ??? private static final ProtectionDomain MY_DOMAIN = Authorization.class.getProtectionDomain(); ??? private static final Authorization PRIVILEGED = ??????????? new Authorization(new ProtectionDomain []{ MY_DOMAIN }); ??? private static final Authorization UNPRIVILEGED ??????? = new Authorization( ??????????? new ProtectionDomain[]{ ??????????????? new ProtectionDomain( ??????????????????????? new CodeSource(null, (Certificate [])null), null ??????????????? ) ??????????? } ??????? ); ??? private static final ThreadLocal INHERITED_CONTEXT ??????????? = new ThreadLocal(); ??? private static final Guard GUARD_REGISTER_CHECK = ??????? GuardBuilder.getInstance("RUNTIME").get("registerGuard", (String) null); ??? private static final Guard GUARD_SUBJECT = GuardBuilder.getInstance("AUTH").get("getSubjectFromAuthorization", null); ??? private static final Set> GUARDS = ??????????? RC.set(Collections.newSetFromMap(new ConcurrentHashMap<>()), Ref.WEAK, 0); ??? /** ???? * Elevates the privileges of the Callable to those granted to the Subject ???? * and ProtectionDomain's of the Callable and it's call stack, including the ???? * ProtectionDomain of the caller of this method. ???? * ???? * @param ???? * @param c ???? * @return ???? */ ??? public static Callable privilegedCall(Callable c){ ??????? Authorization auth = INHERITED_CONTEXT.get(); ??????? try { ??????????? INHERITED_CONTEXT.set(PRIVILEGED); ??????????? if (auth != null){ ??????????????? return privilegedCall(auth.getSubject(), c); ??????????? } else { ??????????????? return new CallableWrapper<>(new Authorization(captureCallerDomain(null), null), c); ??????????? } ??????? } finally { ??????????? INHERITED_CONTEXT.set(auth); ??????? } ??? } ??? /** ???? * Elevates the privileges of the Callable to those granted to the Subject ???? * and ProtectionDomain's of the Callable and it's call stack, including the ???? * ProtectionDomain of the caller of this method. ???? * ???? * @param ???? * @param subject ???? * @param c ???? * @return ???? */ ??? public static Callable privilegedCall(Subject subject, Callable c){ ??????? Authorization authorization = INHERITED_CONTEXT.get(); ??????? try { ??????????? INHERITED_CONTEXT.set(PRIVILEGED); ??????????? Set p = subject != null ? subject.getPrincipals() : null; ??????????? Principal [] principals = p != null ? p.toArray(new Principal[p.size()]) : null; ??????????? return new CallableWrapper<>(new Authorization(captureCallerDomain(principals), subject), c); ??????? } finally { ??????????? INHERITED_CONTEXT.set(authorization); ??????? } ??? } ??? /** ???? * Elevates the privileges of the Callable to those granted to the Subject ???? * and ProtectionDomain's of the Callable and it's call stack, including the ???? * ProtectionDomain of the caller of this method and the Authorization ???? * context provided. ???? * ???? * @param ???? * @param ac ???? * @param c ???? * @return ???? */ ??? public static Callable privilegedCall(Authorization ac, Callable c){ ??????? if (c == null) throw new IllegalArgumentException("Callable cannot be null"); ??????? if (ac != null){ ??????????? Authorization authorization = INHERITED_CONTEXT.get(); ??????????? try { ??????????????? INHERITED_CONTEXT.set(PRIVILEGED); ??????????????? Subject subject = ac.getSubject(); ??????????????? Set p = subject != null ? subject.getPrincipals() : null; ??????????????? Principal [] principals = p != null ? p.toArray(new Principal[p.size()]) : null; ??????????????? Set domains = captureCallerDomain(principals); ??????????????? ac.checkEach((ProtectionDomain t) -> { ??????????????????? if (MY_DOMAIN.equals(t)) return; ??????????????????? if (principals != null){ ??????????????????????? domains.add( ??????????????????????????? new ProtectionDomainKey(t, principals) ??????????????????????? ); ??????????????????? } else { ??????????????????????? domains.add(new ProtectionDomainKey(t)); ??????????????????? } ??????????????? }); ??????????????? Authorization auth = new Authorization(domains, subject); ??????????????? return new CallableWrapper<>(auth, c); ??????????? } finally { ??????????????? INHERITED_CONTEXT.set(authorization); ??????????? } ??????? } else { ??????????? return privilegedCall(c); ??????? } ??? } ??? private static Set captureCallerDomain(Principal [] principals){ ??????? Set