역시나 다를까?! 또 문제가 발생하였다. 새로운 Framework이 적용된 OS는 항상 사용자를 당황케 한다.
역시나 SELinux에서 문제가 발생하였다.
SELinux가 문제가 되는지 가장 빨리 확인하는 방법은 setenforce 0 를 수행하여 SELinux를 비 활성화 시킨다음 문제가 되는 기능을 수행해 보는 방법이다.
예상했던대로 비활성화 시에는 아무런 문제없이 잘 수행되는 기능이 setenforce 1 로 SELinux를 활성화 시키면 다음의 에러를 발생하였다.
처음엔 간단한 문제로 생각하였다. home/svn/publicsvn/test2 이하를 chcon -t httpd_sys_content_t 로 바꾸어주면 문제가 모두 해결되겠거니 하고 생각하였다. ㅠ.ㅠ 그러나 오산이었다.
이때 부터 헤매임이 시작되었다. 구글 신공도 신통치 않았다.
대략 찾아본 페이지들은 다음과 같았다.
http://trac.edgewall.org/wiki/TracOnRhel5
그중 너무나 고맙게도 영감을 주는 글이 있었다.(역시 뭐든지 원리 이해가 필요했다. 조만간 SELinux의 내부 원리를 탐독할 필요가 있을 것으로 생각된다.)
http://lists.edgewall.com/archive/trac/2006-June/008191.html
SELinux는 고맙게도 자신이 거부한 것에 대한 안내를 /var/log/audit/audit.log에 친절히 남겨주고 있었다. 이것을 보기좋게 보여주는 audit2allow -a 명령은 불행하게도 별 도움이 되지 못했다.
다음은 /var/log/audit/audit.log를 직접 분석하여 위의 문제를 해결하는 일련의 과정이다.
음... 이 고비는 일단 넘겼지만 Apache 웹 데몬에서 실행되는 mod_python의 디렉토리, 파일 I/O에 대해 그 대상이 httpd_sys_script_rw_t 를 가지고 있어야 한다니, 벌써부터 예상되는 문제가 떠오른다.
아마 산너머 산이 될까? 다행히 type 부여후 새로 생성되는 것들은 부모의 속성을 이어 받는듯 하다. 정말 다행 스런 일이다.
PHP는 httpd_sys_content_t로 만사 오케이 이건만 ^^;
여하튼 그동안 정확한 원인을 몰라 쩔쩔매던 것이 이렇게 SELinux가 자신이 거부한 것에 대해 친절이 로그를 남기고 있다니 천만 다행이다.
그중 너무나 고맙게도 영감을 주는 글이 있었다.(역시 뭐든지 원리 이해가 필요했다. 조만간 SELinux의 내부 원리를 탐독할 필요가 있을 것으로 생각된다.)
http://lists.edgewall.com/archive/trac/2006-June/008191.html
SELinux는 고맙게도 자신이 거부한 것에 대한 안내를 /var/log/audit/audit.log에 친절히 남겨주고 있었다. 이것을 보기좋게 보여주는 audit2allow -a 명령은 불행하게도 별 도움이 되지 못했다.
다음은 /var/log/audit/audit.log를 직접 분석하여 위의 문제를 해결하는 일련의 과정이다.
음... 이 고비는 일단 넘겼지만 Apache 웹 데몬에서 실행되는 mod_python의 디렉토리, 파일 I/O에 대해 그 대상이 httpd_sys_script_rw_t 를 가지고 있어야 한다니, 벌써부터 예상되는 문제가 떠오른다.
아마 산너머 산이 될까? 다행히 type 부여후 새로 생성되는 것들은 부모의 속성을 이어 받는듯 하다. 정말 다행 스런 일이다.
PHP는 httpd_sys_content_t로 만사 오케이 이건만 ^^;
여하튼 그동안 정확한 원인을 몰라 쩔쩔매던 것이 이렇게 SELinux가 자신이 거부한 것에 대해 친절이 로그를 남기고 있다니 천만 다행이다.
