-
Notifications
You must be signed in to change notification settings - Fork 853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove SecurityManager layer #7928
base: master
Are you sure you want to change the base?
Conversation
Not too much against SM removal. A few assorted comments, just to list what I know of. None of these necessarily means we need to replace SM, but it is something we are loosing.
|
Thanks @mbien Following the Slack conversation on this I've also been running NetBeans a lot with
Sensitive in what way? There are numerous ways that code running in the IDE VM, or even in an external process, can cause the IDE to exit (not to mention any other havoc). I still agree with Alan Bateman's comment on the enhancement request for adding an API to intercept exit - https://bugs.openjdk.org/browse/JDK-8199704 - "There has been several APIs prototyped around this and the conclusion each time is that it probably isn't the right thing to do. If ant or some other task runner is running a task that is hostile to running embedded/in-process then it should be launched into their own process/VM." IMO the benefits of intercepting System::exit are slight in comparison to the complexity introduced, were this the only reason for an agent ...
The agent approach doesn't use the clipboard swap trick to implement this AFAIK. 8114562 The clipboard aspect of this is actually the aspect that concerns me the most. At the same time, given all the clipboard issues on Windows, removing all hacks might at least prove it's not our fault! 😄
With a disabled SM the paste from history is partly broken. It's possibly worth considering what the point of this feature is. If it's external and in-editor text, then that might be achievable without clipboard listening. There are of course now some events fired by the clipboard, but I assume not covering everything we want. OTOH, with the custom clipboard disabled, certain pasting (I noticed file paths particularly) now functions better! |
You can of course replace the launcher in the workflow dev build with the launcher built from this PR at https://github.com/apache/netbeans/actions/runs/11605258427 I wonder if we can find a way to do this automatically for dev builds that change the launcher code??? 🤔 |
JFR will write events for both, halt and exit. the java.lang.Runtime logger unfortunately only logs exit. I asked on the JDK list a few weeks ago, there was also a proposal to log on halt too - but it was decided to not implement it there specifically due to the risk of the callback into application code (logger) which could fail for whatever reason. While debugging, IMO: an annotation processor calling halt, would be as broken as a annotation processor trying figure out your system password. Malicious or not - dependencies like that are filtered out by the java ecosystem, library supply chain reviews etc. You should not blindly use libraries you don't know - only protecting against exit/halt gives only a false sense of safety - a disappearing JVM is the smallest problem if you truly don't trust the code you execute.
I feared the same. However, it seems to work fine with one slight change in behavior: Copy from the editor will only appear in the list after focus loss or after the next copy event (paste works correctly though), everywhere else it appears right away. So there seems to be a special case for copy from editor specifically - this might be also connected to the bug, see comment #7051 (comment) |
update:
|
4865bf5
to
c9c954d
Compare
|
JDK 24 on the horizon we will have to find a solution for the upcoming removal of the deprecated
SecurityManager
mechanism.JEP 486 is a candidate for JDK 24, PR is here openjdk/jdk#21498 (
still openmerged, in build 24+)This PR is an alternative to #3386 and proposes to remove the SM layer entirely, trying to avoid additional complexity of a tracking agent.
To simulate this, I am running NB 23 with
-DTopSecurityManager.disable=true -Djava.lang.Runtime.level=FINE
for severalweeksmonth now without issues, this PR goes one step further and removes the SM layer for a test build - which I tested too.What is SM used for? Why could we likely simply remove it?
System exit blocking:
-J-Djava.lang.Runtime.level=FINE
(will log full stack trace) and also via JFR'sjdk.Shutdown
eventEXIT_ON_CLOSE
System.exit(0)
) but nothing did actually exit NBswing clipboard swap:
sun.awt.AppContext
and writeTransferHandler#SandboxClipboardKey
using reflection, which was only read by Swing if a SM blocked access to the system clipboard (!)--add-opens
hereFile IO tracking:
Tracking calls to Unsafe:
--sun-misc-unsafe-memory-access=deny
Tests:
-> I don't think we actually need the SM layer anymore. This gives us an opportunity to remove a layer without further complicating things with an agent requirement for everything (launcher, tests, archetypes etc).
The agent rewrites bytecode by hand(!) to avoid having to bundle ASM, this could be likely solved by shading ASM till JDK 23 and using the multi-release mechanism + classfile API for 24+ (now final) but this is all extra maintenance cost which we should try to avoid if possible.
Bytecode rewriting can cause followup issues e,g jumping out of methods during debugging sessions without seeing the reason for it in the source.
I do think the agent impl is actually pretty cool but I don't think everything what can be added, should be added if it is avoidable. (also please note that back then NB was still stuck on JDK 8)
this is just a draft - don't panic. This likely will need to be discussed on the mailing list anyway.
But feel free to give the dev build it a try. (the windows launcher might still break things since it has to be build separately unfortunately)