Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v5]
On Thu, 4 Nov 2021 22:11:41 GMT, Weijun Wang wrote: >> New `Subject` APIs `current()` and `callAs()` are created to be replacements >> of `getSubject()` and `doAs()` since the latter two methods are now >> deprecated for removal. >> >> In this implementation, by default, `current()` returns the same value as >> `getSubject(AccessController.getCurrent())` and `callAs()` is implemented >> based on `doAs()`. This behavior is subject to change in the future once >> `SecurityManager` is removed. >> >> User can experiment a possible future mechanism by setting the system >> property `jdk.security.auth.subject.useTL` to `true`, where the `callAs()` >> method stores the subject into a `ThreadLocal` object and the `current()` >> method returns it (Note: this mechanism does not work with principal-based >> permissions). >> >> Inside JDK, we’ve switched from `getSubject()` to `current()` in JGSS and >> user can start switching to `callAs()` in their applications. Users can also >> switch to `current()` but please note that if you used to call >> `getSubject(acc)` in a `doPrivileged` call you might need to try calling >> `current()` in a `doPrivilegedWithCombiner` call to see if the >> `AccessControlContext` inside the call inherits the subject from the outer >> one. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > tiny spec change to be the same as CSR Ah. Yes, making it work in the current `AccessControlContext` mechanism really probably requires teaching `SubjectDomainCombiner` about it, essentially the pre-JEP-411 approach I had come to. If the principals change, that should not only be reflected in what's returned by `getSubject`, but also in what's returned by `combine` (and potentially used in policy decisions). Its documentation would then have to be written a bit carefully for the non-`ThreadLocal` case, to clarify that the supplier's `get` method is called not only at uses of `getSubject`, but also at times when the combiner is applied, such as `getContext` and prior to permission checks. (More or less intuitive,anyway: those are the times the `Subject` _matters_.) That would simply amount to exposing a straightforward method for doing what can already be done today, only without the tedious step of implementing a custom combiner. As a modification to `SubjectDomainCombiner` it could be as simple as changing the instance field to `Supplier` and having both `combine` and `getSubject` begin with a `final Subject subject = subjectSupplier.get();`. The constructor that takes a `Subject` would simply store `() -> s` as the supplier. Adding code to the JEP 411 deprecated components seems a bit of a joyless task, but then it is very little code, and there would then be an API for this use case that would be undisrupted when the deprecated components go away. The extra documentation wording about when the supplier getter is called would, of course, become much shorter and simpler at that point. - PR: https://git.openjdk.java.net/jdk/pull/5024
Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v4]
On Thu, 28 Oct 2021 19:34:21 GMT, Weijun Wang wrote: > Hi, Chap. Thanks for the comment. > > Is it possible you run `callAs` with a "higher level" subject that contains a > link to another more dynamic subject? For example, just make your > `Supplier` a public credential inside. If the caller is not > something you can modify, does it work if you call `callAs` inside `callAs`? I am sorry to be so late in replying. I had initially commented via `security-dev` and I see that comment was added here, and your reply appears in the `security-dev` archives but for some reason never appeared in my inbox. So I will try GitHub's UI this time and see if that goes better. If I remember right, I had looked years ago at making `Subject` itself more clever to handle this case, but was stymied there because `Subject` is final, which was what drove me to the clever-domain-combiner approach. The topic arises in a situation where the JVM is embedded into a larger C application, and actions in the larger application, unknown to Java, can change the principals on whose behalf the work is being done. (The changes, at least in the cases that interest me, are not completely _asynchronous_ with respect to Java; they may happen between application downcalls to Java code, or during upcalls from Java back into the app; it is simply that Java doesn't knowingly initiate them.) There can also be some cost in obtaining the current principal information from the C environment, and of mapping that information into Java `Principal` instances and constructing `Set` representations of those. To eagerly do so at every entry or upcall return is undesirable. To do so only when `current()` is called, as with a `Supplier`, would be desirable. (The clever-combiner approach nearly achieves that, as it only spends cycles at the times the combiner is called.) Naturally, the appeal of integrating with the `Subject` API is to support existing Java code that relies on that API to learn the principals it is acting for. If such code would have to be changed to use the `Subject` in a weird way (such as getting a `Supplier` out of a custom public credential and calling `get` on that), that would squander the benefit of an existing API. As the new implementation simply uses a `ThreadLocal`, it would then be simpler to just use a different custom `ThreadLocal` and avoid the `Subject` API altogether. But in that case the entire benefit of an existing known API has been lost. In your last question, about "`callAs` inside `callAs`", I am not quite sure what you had in mind. - PR: https://git.openjdk.java.net/jdk/pull/5024
Post-JEP411 request: callAs(Supplier) Re: RFR: 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs [v4]
On 10/28/21 13:25, Weijun Wang wrote: >>> New `Subject` APIs `current()` and `callAs()` are created ... >>> where the `callAs()` method stores the subject into a `ThreadLocal` >>> object and the `current()` method returns it That approach is simple and sweet. There is a case it doesn't cover, where the Java runtime is embedded in a larger application where the identity could change during upcalls from Java into the embedding app. For those cases, it is better to be able to pass callAs a Supplier rather than a single unchanging Subject. The effect was achievable in the pre-JEP411 world by installing a suitably clever DomainCombiner, but with the current proposed replacement the ability would be lost. Naturally, it would be simple to support the callAs(Subject s) common case as well, and simply store () -> s in the ThreadLocal. Regards, -Chap
Re: JEP 411, removal of finalizers, a path forward.
On 08/03/21 12:40, Sean Mullan wrote: > It is to the point where I only skim your emails > quickly. I would take the time to write up your ideas in an external place. > It may not go anywhere, but at least you would have a single place where > your proposal, experiments, etc are documented. I would concur with the value of 'an external place' for such discussion. I also have a need to salvage a project from the effects of this JEP, and I have been both psyched that Peter has taken so much initiative in exploring the repercussions and proposing solutions, and at the same time a bit hopeful that others similarly affected (like me, of course, and Alexey Shponarsky who noticed the JSR 233 implications, and others whose use cases I remember reading about in the last nine weeks but haven't reviewed just now) will also be getting ideas into the pot to avoid over-tailoring proposals to one set of particulars. Naturally, that means I need to be keeping up more with Peter's emails, and I also am finding the volume and the medium of email to make that a bit of a challenge. On 08/03/21 20:19, Peter Firmstone wrote: > Maybe we should have a mailing list dedicated to this where we can discuss > and potentially collaborate? In my experience, for the job of working out ramifications and solutions for anything as disruptive as this JEP, an email list quickly and inevitably becomes write-only, when the cognitive burden of connecting today's ideas to those in somebody else's half-remembered email eight weeks ago just becomes too much. On the most productive teams I've served on in the past, a simple wiki turned out much more conducive to collaboration on identifying issues, enumerating ramifications, and hammering out solutions. Instead of a long write-only sequential thread of messages and responses, it would develop into a steadily more complete and organized reference to the issues, solutions found, and those yet to be found. It was never important for that to be a flashy wiki with lots of bells and whistles; what was important was low procedural burden of editing, ease of making and linking new pages, and an underlying VCS so that no history was lost. Is there any such infrastructure currently available, perhaps hosted already by OpenJDK, where an area could be provided to start some pages on the issues and proposals in these email threads? I would be willing to do some curation and get some of the content from these threads into some semblance of initial organization there. I think it would be a natural choice for OpenJDK to host, as the needed work is forced by the consequences of this JEP, and will almost certainly have implications for the further development after 17. (It arguably would have been ideal to host such work earlier in the conception of this JEP, but that's over the dam now.) On 08/03/21 08:15, Ron Pressler wrote: > possibly some callbacks for a small subset of operations that perform > access checks today, say, System.exit and opening a file or socket. I am > not saying this is what should be done, but that the effort involved > is such that I can conceivably see those whose responsibility this > would be agreeing to consider it Indeed, something like that is where I was trying to aim in [1]: Checks that control outwardly-visible effects: - native actions - file operations - socket operations - process operations - ... ? Checks that were necessary "inside baseball" prior to JPMS strong encapsulation: - did you ever really want to have to think about suppressAccessChecks, enableContextClassLoaderOverride, createAccessControlContext, etc., other than because you had to or the checks you cared about were circumventable? Perhaps JPMS strong encapsulation will now be able to ensure that simpler, clearer, faster, cheaper designs are possible for implementing controls over the handful of things one actually wants to control. So the necessary discussion would be focused on what's the size of the small set of outwardly-visible actions one could want to control, and which ones have usable mechanisms existing already (FileSystemProvider, for example), what gaps or blockers might exist in those mechanisms, and confirming their reliability given JPMS strong encapsulation. Probably each of those categories of outwardly-visible ops would be worth at least a page of its own on a prospective wiki, and each such page might see quite a bit of revision and development. It is hard for me to imagine a mailing list discussion in adequate depth and detail being able to arrive at coherence, or indeed to avoid driving burnout and unsubscribe requests. Regards, -Chap [1] https://mail.openjdk.java.net/pipermail/security-dev/2021-May/026177.html
Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller
On 06/29/21 15:39, Weijun Wang wrote: > If I switch to a "non-weak" set or map, then it seems I can safely use > the source string as the key. Will using the Class object as a key prevent > them from unloading? I understand that it's in principle possible for classes to get GC'd, though I don't know how often it happens in typical practical settings. This seems like a question to be approached from the angle of asking what the wanted semantics should be. What should be the effect on warning messages if class a.b.C is loaded and sets a security manager, and is later GC'd, and then a class also named a.b.C is later loaded, and sets a security manager? It seems like a preferred answer to that question would determine whether to make the set weak or not. Regards, -Chap
Re: Authorization Layer post JEP 411
On 06/02/21 19:41, Peter Firmstone wrote: > We need the power of AccessController's stack walk, StackWalker doesn't work > with compiled code, only bytecode. Is this correct? I have not tried it, but the apidocs had led me to understand it did not distinguish much between JITed and interpreted code. Even getByteCodeIndex does not mention any limitation when the frame is JITed Java code (though it does say it will return a negative number in the distinct case of an actual native method). Regards, -Chap
Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries
On 06/02/21 13:30, Maurizio Cimadamore wrote: > This patch replaces `LibraryLookup` with a simpler `SymbolLookup` > abstraction, a functional interface. Crucially, `SymbolLookup` does not > concern with library loading, only symbol lookup. For this reason, two > factories are added: Hi, While I am thinking about this, what will be the behavior when the JVM itself has been dynamically loaded into an embedding application, and launched with the JNI invocation API? Will there be a *Lookup flavor that is able to find any exported symbol known in the embedding environment the JVM was loaded into? (This is the sort of condition the Mac OS linker checks when given the -bundle_loader option.) Regards, Chapman Flack (maintainer of a project that happens to work that way)
Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 06/01/21 12:32, Sean Mullan wrote: > On 6/1/21 2:11 AM, Peter Firmstone wrote: >> Would have really liked to have known about that. > > It was announced on jdk-dev at the time it was launched, with a follow-up > reminder one week later: > > https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html Thanks for that link. I see the announcement said The results of the survey will be made public after the survey closes. That email thread seems to end with the week-later reminder, but I think I found the followup [1]. It links to the results on SurveyMonkey [2], which seem to be viewable if one whitelists www.surveymonkey.com, cdnjs.cloudflare.com, and prod.smassets.net. It also refers to a blog post [3], no longer a good link; also the only occurrence of that URL in the Wayback Machine is a November 2020 archive of its "The content that you're looking [sic] is no longer on this page" page [4]. Is it possible the blogs.oracle.com URL structure just got rearranged? Is there a currently usable link? (My search there for "security manager survey" produces 742 results, six at a time; I haven't found it yet.) Ironically, I easily found a March 2021 blog post [5] "Quiz yourself: Using the SecurityManager class in Java", from which a reader might have come away confident the thing was a going concern. Regards, -Chap [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000929.html [2] https://www.surveymonkey.com/results/SM-PSJ6ZNMZ8/ [3] https://blogs.oracle.com/mullan/securitymanager-survey-results [4] https://web.archive.org/web/20201121023702/https://blogs.oracle.com/mullan/securitymanager-survey-results [5] https://blogs.oracle.com/javamagazine/quiz-yourself-using-the-securitymanager-class-in-java
Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 05/31/21 03:59, Alan Bateman wrote: > The SM survey in 2018 showed that there was some usage too. Out of curiosity, where can I learn more about this survey? Was it the kind of survey that, if I had been hanging around in the right places in 2018, I might have been solicited to respond to? Regards, -Chap
Re: JEP 411: Disable warning message with flag?
On 05/31/21 14:58, Ron Pressler wrote: > However, if the warning were emitted just once, at startup, if the > “allow” value is given rather than on each SM installation, would that > reduce the warning noise for you? In my case not at all, because only one SM is ever installed per process, at startup. But a PostgreSQL installation can start processes rather frequently. (This is a case where it works better to select JVM options that are more client-like than server-like; there is not one long-lived 'server' JVM.) > 1. Help software maintainers know about the deprecation. > 2. Help software users (the more tech-literate ones, those who look at logs) >know when the software they use has properly addressed the issue. > 3. Help us better gauge, however imperfectly and indirectly, the impact of the >deprecation process, and focus us on the more common and impactful uses of >the Security Manager. > > While a flag to suppress warnings doesn't harm goal 1, it severely harms > goals 2 and 3. In my case, goal 2 will be better served by the software users getting release notes from me, and specific warnings generated by my code, speaking directly to their use of PostgreSQL and PL/Java and how that will have to evolve. Therefore I would like an option that says "I'm on it. Please be quiet for now, and go ahead and break in 17+n if I haven't provided my own graceful degradation response for that case by then." Really, my intention is to build the graceful degradation response right now, into the same minor release that will add the option. So even if I fall down a manhole between now and 17+n, the code will be ready for that event anyway. The graceful degradation will have to be a message (again from my code) saying "the fateful Java 17+n has arrived, your functions marked trusted are no longer allowed to run, unless you set this new database option indicating you don't mind them running unrestricted--or revert to Java 17+n-1, or upgrade to the new PL/Java major release that ideally Chap pushed out before falling down that manhole." Naturally, if you provide such an option for my use, it might also get used by the maintainer of package X who just doesn't like looking at the warning, and won't do anything further, and package X will have a train wreck when 17+n arrives. But as long as it's an opt-in option that is clearly so documented, and that maintainer deliberately pushes a commit that adds it, that seems fair. I am not sure what you are getting at with goal 3. Will the warning phone home? > we might consider keeping some hooks that would allow third-parties to create > sandboxing solutions that might be satisfactory, if we’re able to find a good > cost/benefit sweet-spot. Thank you for that. One question I have been wondering about: do you have any internally-tracked metrics that you can share about how many uses of doPrivileged there are in the JDK codebase, and perhaps even a histogram of the stack depth from the doPrivileged down to the affected checked operation(s)? It would be good news if a lot of those are shallow, as in "the checked operation that I know to be taint-free is this one right here that I am wrapping this doPrivileged around." (I'm sure that has always been desirable from a code-review standpoint anyway.) It could also be useful to partition the data according to whether the affected checked operation is something with a real external effect (filesystem, socket, process, thread, ...?), or is something that only had to be checked in the pre-JPMS-encapsulation days in order to fend off circumvention of the policy. I am also sort of wondering what's to become of some of the familiar known rules in the post-SM world. Will getClassLoader() become always allowed, whether the loader is an ancestor or not? Will setContextClassLoader() be a free-for-all? checkGuard()? ...? Is it confidently believed that the JPMS encapsulation suffices for integrity enforcement and non-circumvention with all of those former familiar rules relaxed? Regards, -Chap
Re: JEP 411: Disable warning message with flag?
On 05/31/21 12:45, Chapman Flack wrote: > allow-until-degraded. In 17, that would be treated as allow, but with > the warning suppressed. In 17+n, wherever functional degradation starts, > it should become equivalent to disallow. > ... > the future "degradation", but commit to one easily-detected "degradation" > that will happen no later than any other. Maybe it could be > getSecurityManager()=null, for example, which is easier to test than Ok, that was a small thinko. As long as allow-until-degraded becomes equivalent to disallow as soon as any degradation starts, then catching the exception from setSecurityManager will be a perfectly reliable way to detect the degradation. :) Regards, -Chap
Re: JEP 411: Disable warning message with flag?
On 05/31/21 11:51, Mikael Sterner wrote: > For the record, I want to point out that the latest revision to the > JEP 411 draft didn't solve the issue highlighted below, since applications > embedding a Java runtime still would not be able to suppress the warning > > On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote: >> ... >> I would suggest adding a flag to disable the warning message, for use >> in cases where an application ships to end users with a Java runtime >> included. Because in those cases, the warning is meant for the >> developer of the application and not end users. End users would not be >> the ones providing/upgrading the Java runtime, and in many cases it >> would not be acceptable to have a warning displayed on startup that I was just composing a message to the same effect, for a slightly different use case. The module I maintain for the PostgreSQL RDBMS will simply have to continue using the deprecated API for the near future. I will need to do a minor release that deals with the deprecation and the needed invocation flags, and handles warning its users in a context-appropriate way that is meaningful to them and explains how the future is going to look. I will then need to use the time available during 17's support lifetime to work on a heavily-reengineered major release of the module that will meet its requirements through some other mechanism. In the meantime, users of PostgreSQL with this module installed will derive absolutely zero benefit from having their RDBMS logs spammed with an obscure warning from Java that they can do nothing about every time a DB connection loads the module. I can suggest a couple approaches. One would be to make sure the warning is delivered via the vfprintf hook. As I am using the invocation API to start the JVM, I can use the hook to eat the message. This might not serve others' needs though. Another would be to add another -Djava.security.manager value, allow-until-degraded. In 17, that would be treated as allow, but with the warning suppressed. In 17+n, wherever functional degradation starts, it should become equivalent to disallow. In essence, if I have taken the explicit step of doing a release that adds allow-until-degraded, that is a handoff of responsibility to me. It is now up to me to make sure that users of this module are advised in an appropriate way of what's going down, and it is up to me to make sure what will happen in 17+n is reasonable (in my case, it will have to say "can't run functions of PostgreSQL's TRUSTED variety, unless you back up to Java < 17+n, or move to the next major version of this module"). If I don't handle that responsibility, then it just stops working in 17+n because the flag becomes equivalent to disallow. But by using that flag, I have clearly accepted that responsibility. Meanwhile, users of the RDBMS don't get their logs uselessly spammed. Another ingredient that would help is to be a little less vague about the future "degradation", but commit to one easily-detected "degradation" that will happen no later than any other. Maybe it could be getSecurityManager()=null, for example, which is easier to test than whether doPrivileged() has no ACC effect. That way, without needing a crystal ball to know in which release 17+n the degradation will start, I can already issue a release in advance that will detect and handle it gracefully when it happens. Regards, -Chap
Re: JEP 411: Missing use-case: user functions in an RDBMS
On 05/28/21 10:03, Chapman Flack wrote: > I still think it would be highly desirable for the JDK itself to > adopt some such mechanism, if it can be made sufficiently non-cumbersome, > and perhaps limited just to file operations ... and Process / ProcessHandle operations I am trying to enumerate, in my head, how many kinds of operations there really needs to be some API for applying filters to, in a post-SM, JPMS encapsulated world. As far as effects a JVM can have on the observable outside world, there are: native actions (and --enable-native-access), file operations (and there is -Djava.nio.file.spi.DefaultFileSystemProvider), socket operations (and there are SocketFactories, though how to set them is undocumented and might fall victim to JEP 403), and process operations (how to filter those? only instrumentation?). Am I missing some? It seems to me that a lot of the complexity of the permission model in the pre-JPMS-encapsulation world involved protecting actions that you might not otherwise care about except that they were all needed to make "self-protecting managers" possible, without which the manager could be defeated and then allow actions you'd care about. If JPMS encapsulation can take over most of that busy-work, does that perhaps mean the set of JDK operations that an application might want/need to intercept and filter shrinks down to some concisely-enumerable set of operations that have external effects? I am not sure ... thinking aloud. Regards, -Chap
Re: JEP 411: Missing use-case: user functions in an RDBMS
Hi, On 05/28/21 06:09, Ron Pressler wrote: > Before getting into alternatives and the vision for what would be possible > post-SecurityManager, it would help to explain what the use-case and > requirements are. > > When we talk about untrusted code we usually mean code that you believe > might be malicious and intentionally try to break through any restrictions > you place on it and attack you by any means, including denial-of-service, > while trusted code is assumed to not be malicious. > > From what you’ve written I gather that you only intend to run trusted > “plugins", but wish to restrict their operations so that they don’t break > some application invariants and accidentally interfere with its operation. It seems to me that PostgreSQL's trusted/untrusted distinction (which is a distinction baked into the core PostgreSQL project and therefore common to all of the different programming-language supporting extensions like the Java one that I maintain) is aimed at a sort of intermediate threat model. The key consequence of whether a PL is declared to PostgreSQL with or without the TRUSTED keyword is which database user identities will be able to CREATE FUNCTION in that language. If it is not declared trusted, only the database superuser can create functions using it. If it is declared trusted, the database superuser will be able to GRANT USAGE ON LANGUAGE ... to other database user identities, and they will then be able to CREATE FUNCTION in that language. Here it matters that "database user identities" are usually a pretty small set. Acme Corp's customers won't all have database logins; they probably interact with it through a web app that uses its own credentials for a db connection. The few people with database logins are probably all on Acme payroll, and relatively trusted. If Acme's DBA has said GRANT USAGE ON LANGUAGE java TO bob; then probably Bob is not expected to go installing malicious Java functions. Bob is probably a developer and expected to apply reasonable skill at writing safe ones. The functions, once installed, may be /executed/ by a larger number of database IDs, including possibly via the web apps, so might be executed with /inputs/ crafted as maliciously as external attackers can dream up. So I think it might be said (perhaps the core PostgreSQL devs would hold otherwise) that it's /essential/ for the mechanism to be adequate to protect against oversights and mistakes in Bob's code or the libraries he relies on, including mistakes that might be exposed to malicious external inputs. It's /desirable/ for the mechanism to be robust against a malicious Bob himself, but I'm not sure how many, if any, of PostgreSQL's available PLs could be rigorously proven to be so. > If that is the case, would a “shallow” sandbox, that restricts which APIs > are available to the plugin (e.g. only expose special APIs to interact > with files that go through filtering mechanisms) rather than restrict > low-level operations where they “bottom out” before being passed to the OS, > suffice It's possible a new design in a green field would be able to take that approach. One thing I should have mentioned, and forgot to, is that there's an actual ISO standard, ISO 9075-13, SQL Routines and Types Using the Java™ Programming Language, constraining how this stuff has to work. That's kind of unique among the extension languages; the maintainers of PL/Python or PL/Ruby, lucky devils, can follow their own visions of what SQL functions in those languages should look like. 9075-13 certainly doesn't say anything about a limited or special API that the function will be required to use. That would be a disruptive change to arbitrary amounts of standard-compliant code. (Naturally, as the standard was developed back when nobody thought the J2SE security architecture would be going away, it would have been assumed that the regular API could be used and permissions would control it.) That said, it might be about time for working group 3 to convene for another look at 9075-13; it hasn't been updated in a while, and I don't think it groks JPMS yet either; user code is treated as classpath code. The PostgreSQL core team has a rep on that working group, so maybe it will be possible to plant that idea. I don't think these things move very quickly. Still, I think a change as drastic as "you must now change the API you use to be some different limited version" could be a tough sell. > While a complex, stack-dependent, deep sandbox *could* be used for plugins, > permissions that don’t specify what is forbidden but what is allowed > effectively also severely limit the use of third-party libraries, that > for example, might want to do benign operations with their own files, Well, the chief cause of that problem has historically been that the third-party library devs have been sloppy about getting doPrivileged where it belongs ... or, to put it more charitably, they haven't been given any way less cumbersome than
JEP 411: Missing use-case: user functions in an RDBMS
n developers have had to clean up after them anyway, and that will only get worse after this JEP. But it still seems to me that the JDK itself is a different story. Suppose we simplify the problem to only preserving the information needed to enable implementation of filesystem access controls. All the doPrivileged calls in there because of other obscure permissions that will be abandoned, never mind those. Can there be some way to retain the information that's represented by the ones around taint-free filesystem operations? - some kind of annotation? - some very lightweight doPrivileged replacement that sets a thread-local flag that a filesystem-access filter, if present, could check? - a set of openTaintFree()/deleteTaintFree()/... methods added to the filesystem APIs and used in place of the methods currently called within doPrivileged? Some mechanism like JEP 412's --enable-native-access could allow selected modules to call those methods, and a filter, if supplied, could just leave those alone. Could some idea like this be a manageably-small burden for the JDK devs to keep up to date? Much of the affected code is already very mature and has the doPrivileged()s in the right places. It would be a sort of mechanical transformation of those sites, plus a simple need to be aware in new API development of where the file operations are on tainted values or not. Isn't that already something devs need to be aware of? Regards, Chapman Flack [1] https://tada.github.io/pljava/use/policy.html [2] https://www.postgresql.org/docs/13/sql-createlanguage.html#SQL-CREATELANGUAGE-PARAMETERS [3] Say ... will that unsuppressable warning be written via the vfprintf hook? That would be nice, I could suppress it there then.
