go-ethereum(geth)을 시작하는 systemd 서비스가 있는데, 이 서비스는 제어 콘솔을 제공하는 데 사용되는 Unix 소켓을 생성합니다. 내 문제는 내 사용자와 서비스 사용자가 모두 같은 그룹에 있고 생성된 파일이 자동으로 서비스 사용자와 그룹 모두에 의해 소유되기 때문에 내 사용자가 Unix 소켓에 연결할 수 없다는 것입니다. 그룹에 자동으로 rw 권한을 부여하지 않습니다. 콘솔을 사용하기 전에 터미널에서 실행하여 이 문제를 직접 해결할 수 있지만 sudo chmod 660 /path/to/socket가능하다면 자동으로 이 작업을 수행하고 싶습니다.
내가 시도한 것은 [Service]서비스 파일의 섹션 에 다음과 같은 규칙을 추가하는 것입니다 ExecStartPost=/bin/chmod 660 /path/to/socket. 하지만 이것은 작동하지 않습니다. 서비스 프로세스 시작과 소켓 생성 사이에 지연이 있기 때문이라고 생각합니다. 그러면 명령 ExecStartPost이 실패하고 이로 인해 서비스가 종료되는 것으로 보입니다.
이 문제를 해결하기 위해 제가 볼 수 있는 한 가지 옵션은 파일의 존재를 반복적으로 확인한 다음 파일이 감지되면 파일의 권한을 수정하는 스크립트를 작성하는 것입니다. 그런 다음 규칙을 ExecStartPost=/path/to/script. 같은 맥락에서 더 간단하고 덜 강력한 솔루션이 규칙을 만들 수도 있습니다 ExecStartPost=/bin/bash -c "sleep 5 && /bin/chmod 660 /path/to/socket".
이런 종류의 솔루션이 최선의 선택입니까, 아니면 systemd가 제 목적에 사용할 수 있는 다른/간단한 메커니즘을 제공합니까?
답변1
여기서 기본 지침 원칙은 다음과 같습니다.소켓 을 바인딩하는 것은 무엇이든 AF_LOCAL해당 권한을 설정해야 합니다.. 그렇지 않으면 구불구불한 히스 로빈슨 장치입니다.
데몬 서비스 프로그램이 소켓을 생성하고 바인딩하는 경우 소켓의 권한을 지정할 수 있는 구성 옵션을 찾으십시오. 불행하게도 프로그램 작성자는 사람들이 이 작업을 수행해야 한다고 생각하지 않았을 수도 있습니다.
데몬 서비스 프로그램에 이러한 구성 메커니즘이 없으면 데몬 서비스 프로그램을 만드는 방법을 살펴보십시오.받다이미 열려 있는 파일 설명자로 시작 시 해당 제어 소켓은 메커니즘을 통해 이 파일 설명자에 대한 정보를 전달합니다 LISTEN_FDS(아마도 연결 요청을 수락하는 청취 소켓일 것입니다). 그런 다음 소켓을 생성 및 바인딩하고 해당 권한을 설정하는 역할을 담당하는 서비스 관리입니다.하다손잡이가 있습니다.
Accept=No그런 다음 적절한 ListenStream설정(아마도 제어 인터페이스는 스트림 소켓 1일 것임)과 설정을 포함하여 해당 소켓을 설명하는 시스템 소켓 장치를 설정합니다 SocketMode=0660.