Inherit supplementary groups if no group has been specified #341
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
|
Looks good. Is it worth using calloc() for group list allocation should the group list change during the operation? Mind adding updating the config man page? |
|
I've already updated the manual file with information regarding the Regarding the race condition, I've handled that in dca7ed9 where I use the returned number of entries from the second call instead of those from the first. This means that if the user's group gets smaller the remaining entries in the gid array are ignored. If the group list gets larger, it will fail and get a fatal error. |
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.
This PR changes the behaviour of permission dropping, by inheriting user's supplementary group if no group has been explicitely specified in the configuration file.
The reason behind this PR is that I need to connect from sniproxy to a stunnel4 UNIX socket. Said sockets are created in Debian with permission 775 and user stunnel4, which means only users in the stunnel4 user and group can connect to said tunnels.
I thought about adding the sniproxy user to stunnel4 group so it could access the pipe, but it didn't work, and I spent quite some time figuring out why it was getting a connection refused even though the groups were properly set.
This PR thus allows using more than one group in the sniproxy user, which is more natural and behaves as in sudo or start-stop-daemon where the supplementary groups are also setup.