"plugin start": spawn plugin processes with a non-0 umask #3375
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fd36cba to
de6c5b4
Compare
|
We should leave umask unchanged, from whatever it was at start? |
|
Ok, will make it a |
|
Needs a changelog entry, otherwise looks good to me 👍 |
de6c5b4 to
087df81
Compare
|
Modified to use initial umask instead, and added the Changelog |
Changelog-Added: JSONRPC: 'plugin start' now restores initial umask before spawning the plugin process
087df81 to
ab28258
Compare
|
ACK ab28258 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since they are currently spawned with a umask of 0 (set when daemonizing), plugins will create files with 666 and directory with 777 permissions. This might not be a big deal but
22may be a more expected default for plugin developers ?