On 24/03/2017 10:09, Andrew Dinn wrote:
:
The point I think Remi is making is that /pragmatically/ we will be back
in pre-JDK6 land with the current proposed default. You blithely use the
words 'the launch script can specify' above. In practice, your use of
the definite article belies the fact that there is not 'a' launch script
but a plethora of command lines and scripts employed by a multitude of
users. It is the practical concerns involved in managing the complexity
that that multiplicity implies I am concerned with. I think I probably
speak for Remi here too and, perhaps, others agent implementors. I'd
like to see a much better argument for the security benefits of this
change before it gets rolled into a release.
Just to re-cap, the Attach API has several users:
1. The troubleshooting tools such as jcmd, jstack, and jmap
2. Management tools that use the API to start a JMX agent
3. Tools that load JVM TI or java agents into running VMs.
The proposal here does not impact #1 and #2, this is why I said thaht it
does not bring us back to JDK 5. Opinions will differ but I think #1 is
by far the most useful aspect to the attach mechanism.
#3 has always been controversial. The issue in JIRA might be only a few
days old but the concerns with the dynamic agent loading part go back
years (more like 10 years). I did the original attach API back in JDK 6
and regret that the agent loading part wasn't opt-in from the start.
Yes, it's hard to change it now. In general then we've done a lot of
changes in JDK 8 and JDK 9 to make the platform more secure by default,
this fits with that direction. You mentioned in the other mail about the
mechanism being restricted to same uid/gid but that is also a bit too
restrictive (there are complaints periodically on this). I expect it
will have to be relaxed at some point to allow root, users with specific
capabilities, Windows Terminal Server environments, etc. In addition,
the changes in JDK 9 makes it too easy to use the attach API from
regular applications or libraries - something that was never the
intention. I don't think it's possible to lock things down from the API
side of things, it has to be the VM side.
If it is changed to needing to opt-in then the question comes up as to
how many tools are impacted and what is the impact. I can't say exactly
how many tools using this API to load code into running VM but it
doesn't seem to be many. The impact would be that these tools would need
to document that the VM needs to be launched with the opt-in option in
order to use the tool in this way. It shouldn't impact the IDE
environment too much. Server deployments where profilers are other tools
would need the CLI option, that could be disruptive to add initially.
-Alan
