On Wed, 27 Mar 2024 18:28:07 GMT, Kevin Walls <kev...@openjdk.org> wrote:
>> It looks like the test only inspects a thread and a java object. Perhaps you >> could add tests for additional VM objects. Maybe grab a frame PC from a >> thread stack trace. > >> It looks like the test only inspects a thread and a java object. Perhaps you >> could add tests for additional VM objects. Maybe grab a frame PC from a >> thread stack trace. > > Yes - added a couple of metadata tests, and a compiled method test, which > gets an address from Events info. We know that should resolve to a compiled > method (if we have such an event, so this copes if there are none). > > > Also the VM.info and Thread.print runs with the CommandExecutor are now > silent. They are long, and max out the test log file and make it truncate. > That output could mainly be useful if the regexes can't match items, but the > output format should be reproducible in a new run. Also if we fail to find > something we need, like a thread id, it will print the full output it > searched. @kevinjwalls Hi Kevin. Sorry to offer a drive-by comment but I have been watching this thread and I can understand why @tstuefe is expressing his concern about the potential for security issues when it comes to using jcmd to expose JVM internals. Exposure of details like a thread/stack/metadata value address or a datum embedded at such a location does look to me like something bad agents might be able to profit from. The danger is not just being able to retrieve specific details of the layout or content of JVM structures themselves, but the opportunity to use that knowledge to upgrade a weak security hole like, say, a memory exposure, into a stronger targeted attack that knows where or to what it might want to apply the crowbar. So, first off, please understand that I am not suggesting there *is* a problem here. I am happy to accept your conclusion that your proposed jcmd changes do not expose new data to users who ought not to be able to view either via local or via remote accesses. However, not being an expert when it comes to the jcmd/DCmd implementation, I'm not sure I really understand why that is so from your current explanation. In particular I don't understand what you said about visibility of different commands for local and remote access. That confession of my own ignorance is not really of any immediate importance as I have no intention of trying to review this change. However, I still feel it might be useful if you could summarize on this JIRA precisely what security safeguards are currently in place when it comes to running specific jcmds/DCmds and why that means exposure of JVM internal details via jcmd, whether locally or remotely via JMX, will only be to a safe audience of users. That would help any maintainer/developer who refers to this JIRA to follow how those safeguards apply to the proposed commands (in particular it might be of great help to those performing and assessing the correctness of backports). However, it would probably also as a prophylactic to ensure that any future development work does not inadvertently lead to unexpected exposure, which I think is the thing Thomas is more worried about. Indeed, as Thomas suggested, a clear statement of what policies and mechanisms are (or should be) in place to ensure jcmd content is securely viewable might be a good starting point for you and/or Thomas to raise follow-up JIRAs if needed to: 1. add comments to the code base to ensure devs to not inadvertently add or modify new DCmds in a way that prejudices security 2. enable a review of the existing DCmd organization to see if a better grouping of commands or assignent of access restrictions might be warranted ------------- PR Comment: https://git.openjdk.org/jdk/pull/17655#issuecomment-2025282602
