-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
8297451: ProcessHandleImpl should assert privilege when modifying reaper thread #11309
Conversation
…per thread This commit guards thread modifications for the process reaper thread with doPrivileged.
👋 Welcome back rjernst! A progress list of the required criteria for merging this PR into |
Webrevs
|
Hi @rjernst Thanks for taking this one on. I agree with adding the privileged blocks around the calls to Thread::setName, but the usage raises a warning which fails the build. It might be cleaner and easier to refactor into a privilegedThreadSetName helper method. Additionally, I noticed that there is an existing test that can be modified slightly to cover this. I've put these two comments / suggestions in the form of a PR and raised it against your branch. rjernst#1 |
*/ | ||
public static Thread newSystemThread(String name, Runnable target, | ||
long stackSize, int priority, | ||
boolean daemon) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this overload, I think that it will be useful for the future too. ( it never seems to matter how many variants of these factories we have, we still need one more :-) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to to avoid creating new factories when the desired function can be done on the resulting thread.
Such as setDaemon()
and setName()
, etc.
It does avoid the doPriv in this case, but is not necessary and when the security manager goes away, will leave around clutter (duplicated) functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking beyond this specific change, there is a lot of potential use for this new factory elsewhere in the code. It also avoids similar bugs from possibly reoccurring (by having the setDaemon call inside the factory).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the interest of making progress, let’s revert the change to the factory. This can be done separately, if at all.
Add privileged helper method and update existing test
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@rjernst This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 43 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@ChrisHegarty, @AlanBateman) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks okay. Not important but can eliminate the casts from privilegedThreadSetXXX methods if you separate the creation of the PrivilegedAction from the doPriv call.
/integrate |
I chose to keep it as is since there was already another doPriv in the file that uses the cast style. |
/sponsor |
Going to push as commit 50f9043.
Your commit was automatically rebased without conflicts. |
@ChrisHegarty @rjernst Pushed as commit 50f9043. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This commit guards thread modifications for the process reaper thread with doPrivileged.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11309/head:pull/11309
$ git checkout pull/11309
Update a local copy of the PR:
$ git checkout pull/11309
$ git pull https://git.openjdk.org/jdk pull/11309/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 11309
View PR using the GUI difftool:
$ git pr show -t 11309
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11309.diff