Tengo un servicio systemd que inicia go-ethereum (geth), que luego crea un socket Unix que se utiliza para proporcionar una consola de control. Mi problema es que mi usuario no puede conectarse al socket Unix porque, aunque mi usuario y el usuario del servicio están en el mismo grupo y el archivo creado es automáticamente propiedad tanto del usuario del servicio como del grupo, el proceso geth no No otorga automáticamente permiso rw al grupo. Puedo solucionar esto yo mismo ejecutando sudo chmod 660 /path/to/socketdesde una terminal antes de usar su consola, pero me gustaría hacerlo automáticamente si es posible.
Lo que intenté fue agregar una regla como esta a la [Service]sección del archivo de servicio: ExecStartPost=/bin/chmod 660 /path/to/socket. Sin embargo, creo que esto no funciona porque hay un retraso entre el inicio del proceso de servicio y la creación del socket. Luego, el ExecStartPostcomando falla, lo que a su vez parece provocar que el servicio se cierre.
Una opción que puedo ver para solucionar este problema es escribir un script que verifique la existencia del archivo repetidamente y luego modifique los permisos del archivo una vez que se detecte. Entonces podría cambiar la regla a ExecStartPost=/path/to/script. Una solución más sencilla y posiblemente menos sólida en el mismo sentido podría ser establecer la regla ExecStartPost=/bin/bash -c "sleep 5 && /bin/chmod 660 /path/to/socket".
¿Es este tipo de solución la mejor opción o systemd proporciona algún otro mecanismo más simple que podría usarse para mi propósito?
Respuesta1
El principio rector básico aquí es quelo que sea que une el AF_LOCALsocket debe establecer sus permisos. Hacer lo contrario es un artilugio desvencijado de Heath Robinson.
Si el programa de servicio demonio crea y vincula el socket, busque opciones de configuración que le permitan especificar los permisos del socket. Desafortunadamente, es posible que los autores del programa no hayan pensado que la gente necesitaba hacer esto.
Si el programa de servicio demonio no tiene dicho mecanismo de configuración, entonces intente hacer que el programa de servicio demoniorecibirsu socket de control al inicio como un descriptor de archivo ya abierto, pasó información sobre este descriptor de archivo a través del LISTEN_FDSmecanismo (ya que presumiblemente es un socket de escucha que acepta solicitudes de conexión). Luego, es la gestión de servicios la responsable de crear y vincular el socket y establecer sus permisos, lo que systemdhacetiene perillas para.
Luego configure una Accept=Nounidad de socket systemd que describa ese socket, incluida la configuración adecuada ListenStream(ya que presumiblemente la interfaz de control es una de socket de flujo) y una SocketMode=0660configuración.