You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if protocol messages like querying service status were available unprivileged so that you could e.g. dinitctl --system list as a user.
The way I'm thinking it could be done is:
add a parameter to dinit specifying the requested permissions for the socket; default to 666 on supported platforms, and 600 elsewhere for system dinit (the parameter would let people e.g. force it to 600 always if they don't want unprivileged users to access that), user dinit would have 600 always by default (doesn't really make sense to allow random users to access other random users' control socket)
add code to check the uid of the connection via SO_PEERCRED; block access to "write" protocol messages, as well as probably specific other messages such as GETALLENV, by issuing a protocol error - we could also issue a specific return message like some kind of "permissions denied" and make it recoverable
The code would be behind a feature flag, therefore supported only on OSes that have socket peer credentials (Linux/BSDs/Darwin all support those for TCP sockets though with slightly different API)
I could implement this but I want to hear your thoughts on it first...
The text was updated successfully, but these errors were encountered:
Sorry for being slow to respond, I'm travelling at the moment and busy.
Basically I think this is reasonable if (as you suggested) it's behind a feature flag and can be disabled. In terms of implementation it needs to be done very carefully - it introduces a change in the security model since up until now Dinit does not need to concern itself with walling itself off from unprivileged processes (the idea has been that access to the control socket requires privilege). It would be good to keep very clear in the code the privileged vs unprivileged operations - possibly even moving them into separate source files, and/or big comment markers to delimit them.
It would be nice if protocol messages like querying service status were available unprivileged so that you could e.g.
dinitctl --system list
as a user.The way I'm thinking it could be done is:
The code would be behind a feature flag, therefore supported only on OSes that have socket peer credentials (Linux/BSDs/Darwin all support those for TCP sockets though with slightly different API)
I could implement this but I want to hear your thoughts on it first...
The text was updated successfully, but these errors were encountered: