upstart
보안을 위해 권한이 없는 사용자로 실행해야 하지만 권한이 있는 포트 443을 바인딩해야 하는 (Ubuntu 14.04)에서 시작한 데몬을 개발 중입니다 .
setcap
실행 파일을 설정하는 데 사용하는 함수 CAP_NET_BIND_SERVICE
입니다(스크립트가 아님). 저는 이를 "허용된", "유효한" 및 "상속된" 세트( setcap 'cap_net_bind_service+eip' EXEC
)로 설정했습니다.
su
권한이 없는 사용자로 직접 실행할 수 있으며 제대로 작동합니다. 포트를 올바르게 바인딩하고 /proc/PID/status
비트가 설정된 올바른 기능 마스크를 표시합니다.0x400
그런데 이를 통해 서비스를 시작하면 upstart
바이너리에 지정된 기능으로 실행되지 않고 실패합니다 bind()
( EPERM
). /proc/PID/status
표시 기능 마스크는 모두 0입니다.
어떤 아이디어가 있나요?
답변1
나는 이제 이것이 버그라고 생각하며 upstart가 "예상 데몬"(즉, 시작 시 두 번 분기하는 서비스)을 사용하여 서비스를 시작하는 방식과 관련이 있다고 생각합니다. 기능 (7)을 사용하는 프로세스에서 strace를 사용하면 해당 기능도 무시된다는 것을 알았습니다. 나는 대기할 PID를 결정하기 위해 신생 기업이 PID를 얻을 수 있을 만큼 오랫동안 "expect daemon"으로 지정된 서비스를 추적하여 커널 기능 메커니즘이 실패할 것이라고 의심합니다. 따라서 버그는 함수가 프로세스 추적과 상호 작용하는 방식과 "expect 데몬"을 사용하여 서비스를 시작할 때 upstart가 프로세스 추적을 사용한다는 사실에 있습니다(이것은 가정입니다).
간단한 테스트로:
- 작은 C를 쓰세요프로그램포트 443에 바인딩합니다(함수 (7)에는 Python과 같은 해석 언어를 사용할 수 없습니다).
- 루트가 아닌 사용자로 실행하고 권한 부족으로 인해 바인딩에 실패하는지 확인하세요.
- 애플리케이션에 대한 CAP_NET_BIND_SERVICE 기능을 설정합니다.프로그램(루트로 실행
setcap 'cap_net_bind_service+epi' PROGRAM
) - 루트가 아닌 사용자로 실행하고 이제 성공하는지 확인하세요.
- 이제 strace로 실행하여 실패하는지 확인하세요.
i
(엄밀히 말하면 3단계에서 상속된 기능 세트(플래그)는 이 테스트를 위해 수정할 필요가 없지만 forks()
내 데몬과 같은 프로세스에는 필요합니다.)
feature(7) 매뉴얼 페이지에는 프로세스 추적과 함께 사용해서는 안 된다는 내용이 없기 때문에 이 문제와 관련하여 커널에 버그를 신고하겠습니다.
답변2
한 가지 해결 방법은 Expect Fork 또는 Expect 데몬을 사용하지 않고 데몬을 포그라운드 프로세스로 만드는 것입니다. 그러면 Upstart는 이를 전혀 추적하지 않습니다.