"개인용 /tmp는 좋은 생각 같아요... 나에게는 효과가 있고 더 안전하므로 1970년 이후로 /tmp가 /tmp가 될 것으로 기대했던 세계의 모든 UNIX 사용자에게 재배포합시다... ..." 얻다? 폭발, 파괴, 그리고 몸에 불이 붙습니다.
Debian 9에서 private /tmp를 비활성화하려고 하므로 다음 사이트의 지침을 따랐습니다.
https://www.maxoberberger.net/blog/2017/10/debian-9-private-tmp.html
보기에는 좋아 보였지만 그렇지 않았고 마음이 아팠습니다.
에 오버레이 파일을 생성하여 비활성화하려고 하면 /etc/systemd/system/apache2.servicesystemd가 나를 완전히 무시하는 것 같습니다.
파일을 직접 편집해야 합니다.
/lib/systemd/system/apache2.service
이것은 효과가 있지만이건 정말 좋은 생각이 아니야특히 시스템을 업그레이드하는 경우! 오늘 unattended-upgrade실행했는데 private tmp 때문에 모든 것이 깨졌습니다. 그런 다음 다시 비활성화해야 했습니다. 우리는 콘솔에서 실행되는 다른 레거시 시스템과 통신하는 웹 시스템을 사용합니다...tmp를 통해 통신합니다.
내가 뭘 잘못했나요? 서버를 다시 시작해야 하나요?
답변1
systemctl daemon-reload시스템 단위 파일을 다시 로드하는 단계가 누락되었습니다 . 먼저 이렇게 하고,그 다음에서비스 다시 시작
전체 서버를 다시 시작해도 작동하지만 필수는 아닙니다.
PS 링크된 기사와 동일한 문제가 있는 경우 apache가 cronjob이 작성한 일부 파일을 읽으려고 하면 /tmp를 사용하여 이러한 파일을 처리하지 않음으로써 이 문제를 보다 세밀하게 해결할 수 있습니다. /tmp 사용과 관련된 보안 문제에 대해 걱정하지 않고 cronjob에서 쓸 수 있는 디렉터리를 구성할 수 있습니다. 즉, 다른 UID는 원하는 프로세스가 이를 유지하기 전에 /tmp에서 하드코딩된 소켓 이름/하위 디렉터리를 훔칠 수 있습니다.