man: document footgun on SocketUser= #32503
Conversation
github-actions
bot
added
documentation
please-review
|
Important An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released. |
`SocketUser=` might have inconsistent results if they're inside a path specified by `RuntimeDirectory=` (or any other directory option where directories are chown'ed on startup). Especially in the case of creating a socket-activated service that's reachable for another user (the most common usecase for this option), it feels prudent to document this caveat, considering how frequently these unix domain sockets happen to be created in /run. I just ran into this, and it seems systemd#8635 is at least another documented case.
flokli
force-pushed
the
socketuser-chown
branch
from
cd01617
to
1c7359c
Compare
| Note that this might not have the desired effect if a socket happens to be inside a directory also | ||
| referred to in a <varname>RuntimeDirectory=</varname>, <varname>StateDirectory=</varname>, | ||
| <varname>CacheDirectory=</varname>, or <varname>LogsDirectory=</varname> of any service, due to the | ||
| change of ownership caused by these options. |
There was a problem hiding this comment.
I am not following? What's the problem?
There was a problem hiding this comment.
As in the issue description, SocketUser= is used to make the socket file owned by a different user than the service. If you however also have RuntimeDirectory= set, and your socket file is in there, both places try to chown this.
The common example for breakage is myservice wanting a /run/myservice/sock to be owned by otheruser.
If myservice also sets RuntimeDirectory=myservice, which chowns to myservice user, these two things race.
There was a problem hiding this comment.
RuntimeDIrectory= doing the chown is well-documented, but people using SocketUser= might not be aware of this conflicting. Hence the pointer.
|
Poke - can we get this in? |
SocketUser=might have inconsistent results if they're inside a path specified byRuntimeDirectory=(or any other directory option where directories are chown'ed on startup).Especially in the case of creating a socket-activated service that's reachable for another user (the most common usecase for this option), it feels prudent to document this caveat, considering how frequently these unix domain sockets happen to be created in /run.
I just ran into this, and it seems
#8635 is at least another documented case.