Add options to change mode, user, and group of API server socket #612
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.
Closes #604!
This PR adds three new options to klippy.py, as seen from this truncated help page:
These options allow user to change the user, group, and file mode of the API server socket, i.e.
/run/kalico/ud_sock.For example, these options...
...will create
/run/kalico/ud_socklike so:From a UNIX permissions perspective, it's a good idea to have Moonraker and Kalico run as different users. Kalico typically has access to hardware, video, network, etc., and if Moonraker runs as the same user, then Moonraker also has access to these things. Moonraker is an API server that should only be communicating with Kalico, and should not have access to the extra privileges Kalico requires. For example, if an RCE in Moonraker is discovered, then the attacker will have access to these elevated permissions.
With this PR, the principle of least permissions can be applied between Kalico, Moonraker, and other software. The socket can be given 660 permissions with a special group, and as long as the Moonraker user is in this group, then it can read/write to the socket without additional permissions.
If the end user doesn't need these features, then no biggie: this PR is not a breaking change, and there will be no behavioral difference before and after this PR without these options set 👍
Checklist