> we’ve begun to explore means other than the flag to allow a tool to load an > agent at runtime
How about restricting access to the jcmd socket. For in-VM code it can be blocked at the filesystem implementation level, and for sub-processes by using the operating system APIs to determine if the other side of the socket is part of the same process tree at connect time. This would avoid the need for new UI to re-enable existing jcmd functionality, whilst preventing code loaded into the VM from connecting back to that same VM. Only truly external tools could trigger agent loading, or modules that had been given permission to do that. That is assuming native code is restricted of course but that's a whole other kettle of fish. I don't quite understand how the plan is meant to work when it reaches that stage. JNI is so widely used and so many libraries would break that you'd either just immediately see workarounds appear, like build systems concatenating lists of flags from META-INF files, or it'd just cause a lot of chaos and upgrade rejection. It'd also have to be dynamically controllable for plugins, so then you'd also get people running their apps inside classloaders that auto-grant any request to load native code. There must be a better way? Maybe the problem can be recast as one of build-time observability? One concept I experimented with for my own build system is the notion of "control reports", a generalization of lockfiles. The build generates text files describing things you care about, and these are then checked in to vcs. There is a build mode that doesn't write the generated reports on disk, instead it verifies there's no difference and exits if there are. By checking the reports into version control and using OWNERS files + code reviews various policies can be enforced. In this context it'd work like so: the JVM would be changed to look for a flags file in the JAR containing the main class/main module as part of its startup. JVM flags can thus be shipped as part of the app, formalizing an already existing convention that's today implemented with shell scripts. Build systems can generate this flag file from their existing lists of JVM flags, and/or compute it automatically by merging flag files found in any library JARs. For people who don't care about deprivileging libs (prototyping, learners, people who only use in-house code etc) this will keep things working as it does today. For people who wish to use this new security feature they can review the generated flag file and check it in. Now if they add a dependency on a library that needs to use panama, jni, an agent, opened packages etc, this will become visible as added lines in the flag file, can be pushed back on when the commit is reviewed, and by placing an OWNERS file in the directory containing the report tech leads can allow delegates to add dependencies without being able to change JVM flags.
