JEP 411: Disable warning message with flag?
Chapman Flack
chap at anastigmatix.net
Mon May 31 21:53:56 UTC 2021
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
More information about the security-dev
mailing list