사용자 홈 디렉토리에 있는 소켓(chmod 777)을 통해 작동하도록 uwsgi 및 nginx를 구성했지만 nginx는 소켓(13: Permission Denied in error.log)에 액세스할 수 없습니다. 777 chmod를 사용하여 소켓을 /tmp/로 이동하려고 시도했지만 오류가 발생했습니다.2: No such file or directory
2021/09/21 19:40:16 [crit] 68278#0: *17 connect() to unix:///tmp/my.sock failed (2: No such file or directory) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/my.sock:", host: "****"
2021/09/21 20:10:16 [crit] 517#0: *1 connect() to unix:/home/***/.deploy/my.sock failed (13: Permission denied) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/***/.deploy/my.sock:", host: "***"
PS selinux가 비활성화되었습니다.
답변1
답을 얻기 전에 chmod 777을 사용하거나 SELinux를 비활성화하는 나쁜 보안 습관을 깨기 위해 모든 노력을 기울여야 합니다. 오히려 항상 올바른 권한을 알 수 있도록 UNIX 권한 모델을 완전히 배워야 하며, SELinux가 제공하는 추가 보안 계층의 이점을 누릴 수 있도록 서비스를 구성해야 합니다.
따라서 사용자의 홈 디렉토리에 깊이 묻혀 있는 소켓이 작동하지 않는 이유는부모의디렉토리의 권한으로 인해 필요한 액세스(이 경우 search x)가 금지되었습니다. 모든 상위 디렉터리의 권한을 한 번에 확인하고 검색 권한을 허용하지 않는 디렉터리를 수정하는 데 사용합니다 namei -l /home/***/.deploy/my.sock(대부분 /home/***).
chmod +x /as/needed
또한 필요에 따라 소켓 자체에 대한 권한과 소유권을 수정하는 것을 잊지 마세요.
완전성을 위해 소켓을 찾을 수 없는 이유 /tmp는 시스템 서비스로 실행되는 nginx가 시스템 /tmp디렉터리에 액세스할 수 없기 때문입니다. Systemd는 이를 시작하여 PrivateTmp=true고유한 개인 디렉토리가 생성되고 nginx가 /tmp해당 디렉토리에 네임스페이스를 지정합니다. 이것이 모든 /tmp/xxx-systemd-private-foo디렉토리의 목적입니다.