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
When using a UNIX-domain socket, it’s useful to be able to control access permissions. For example, I want Apache (running as the www-data user) to be able to connect to Jenkins (running under the jenkins user and jenkins group). Since nothing special is done when creating the UNIX-domain socket, with Jenkins running under a typical 0022 umask, I end up with a socket owned by jenkins:jenkins and mode 0755, which Apache can’t connect to (under Linux, you have to have write permission on a socket to connect to it). It would be useful if we could control the file permissions, or ideally even better also the owning group, of the socket. Barring that, just opening the permissions to be writeable by all would be sufficient, since one can also just put tighter controls on a containing directory. But it’s not possible to broaden the permissions using a containing directory, which means AFAICT right now the only options are to (1) run the frontend HTTP server under the jenkins user (which is obviously bad for security) (2) change Jenkins’s umask to 0002 (which is probably bad for security too), or (3) set up some kind of weird service dependency thing to chmod or chgrp the socket file after Jenkins starts up (which is probably really hard to get right in the face of Jenkins restarting itself and presumably recreating the socket file when doing so).
#211 would also fix this nicely since systemd has a fairly rich language for setting file permissions on sockets.
Upstream changes
No response
Are you interested in contributing this feature?
No response
The text was updated successfully, but these errors were encountered:
There’s a reasonable workaround. Using ExecStartPost=chmod … and ExecStartPost=chgrp … seems to work quite reliably, even running when you do a restart from the Jenkins web UI. So this is a fairly low-priority nice-to-have thing IMO.
What feature do you want to see added?
When using a UNIX-domain socket, it’s useful to be able to control access permissions. For example, I want Apache (running as the
www-data
user) to be able to connect to Jenkins (running under thejenkins
user andjenkins
group). Since nothing special is done when creating the UNIX-domain socket, with Jenkins running under a typical 0022 umask, I end up with a socket owned byjenkins:jenkins
and mode 0755, which Apache can’t connect to (under Linux, you have to have write permission on a socket to connect to it). It would be useful if we could control the file permissions, or ideally even better also the owning group, of the socket. Barring that, just opening the permissions to be writeable by all would be sufficient, since one can also just put tighter controls on a containing directory. But it’s not possible to broaden the permissions using a containing directory, which means AFAICT right now the only options are to (1) run the frontend HTTP server under thejenkins
user (which is obviously bad for security) (2) change Jenkins’s umask to 0002 (which is probably bad for security too), or (3) set up some kind of weird service dependency thing tochmod
orchgrp
the socket file after Jenkins starts up (which is probably really hard to get right in the face of Jenkins restarting itself and presumably recreating the socket file when doing so).#211 would also fix this nicely since
systemd
has a fairly rich language for setting file permissions on sockets.Upstream changes
No response
Are you interested in contributing this feature?
No response
The text was updated successfully, but these errors were encountered: