나는 대학의 시스템 관리 부서에서 일하면서 아마도 흔한 일을 우연히 발견했지만 꽤 충격적이었습니다.
모든 public_html 디렉토리 및 웹 영역은 웹 서버에 대한 읽기 권한과 함께 afs에 저장됩니다. 사용자는 public_html에 PHP 스크립트를 사용할 수 있으므로 PHP (및 기본 웹 파일)에서 서로의 파일에 액세스 할 수 있습니다.
이로 인해 .htaccess 비밀번호 보호가 완전히 쓸모 없게 될뿐만 아니라, 사용자는 mysql 데이터베이스 비밀번호와 유사한 민감한 정보가 포함 된 PHP 소스 파일을 읽을 수 있습니다. 또는 다른 사람이 웹 서버가 쓰기 액세스 권한을 가진 디렉토리 (예 : 개인 로그 또는 제출 된 양식 데이터 저장)를 가지고있는 디렉토리를 발견하면 해당 계정에 파일을 저장할 수 있습니다.
간단한 예 :
<?
header("Content-type: text/plain");
print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd");
?>
이것이 일반적인 문제입니까? 일반적으로 어떻게 해결합니까?
최신 정보:
입력 주셔서 감사합니다. 불행히도 간단한 대답이없는 것 같습니다. 이와 같은 대규모 공유 환경에서는 사용자에게 이처럼 많은 선택권이 주어지지 않아야합니다. 내가 생각할 수있는 가장 좋은 방법은 모든 “public_html”디렉토리의 기본 구성에서 “open_basedir”을 설정하고 suphp를 실행하고 깨끗한 PHP 만 허용하는 것입니다 (cgi 스크립트 없음, 백틱으로 외부 명령 실행 등).
이와 같은 정책을 변경하면 많은 문제가 발생하고 사용자가 자신의 갈퀴를 잡고 우리를 쫓아 갈 수 있습니다 … 설정 변경 방법에 대한 결정을 내리면 동료와 논의하고 업데이트 할 것입니다.
답변
답변
내 제안은 ( open_basedir
호스트 단위로 및 유사한 지시문을 통해) 파일에 대한 PHP의 액세스를 제한 하는 것입니다. 예를 들어 htpasswd
파일을 저장하는 디렉토리는 아닙니다 .
다음과 같은 디렉토리 구조 :
/Client
/auth
/site
/www_root
/www_tmp
이 요구 사항을 충족시킬 open_basedir
수 있습니다. /Client/site
안전하게 가리킬 수 있고 htpasswd
파일을 저장할 수 있습니다 /Client/auth
( .htaccess
파일을 사용하거나 httpd.conf
대신 적절한 위치를 가리 키도록 수정).
오프닝 다른 사람이 파일을, 그리고 혜택으로 악의적 인 사용자가에서 물건을 읽을 수 없습니다에서이 클라이언트를 방지 /Client/auth
같은 시스템에 (또는 다른 것을 /etc/passwd
🙂
open_basedir 및 호스트 별 구현에 대한 자세한 내용 은 http://php.net/manual/en/ini.core.php 를 참조 하십시오 .
답변
대부분의 공유 호스트는 각 사용자의 public_html 디렉토리 (또는 각 사용자가 고유 한 vhost를 가지고있는 경우 vhost)의 htaccess 파일에서 open_basedir 구성을 정의하기 때문에 일반적인 문제는 아닙니다.
예 : .htaccess 파일 :
# Assuming these are not set globally - its good practice to limit:
php_flag magic_quotes_gpc off
php_flag magic_quotes_runtime off
php_flag register_globals off
php_flag short_open_tag off
php_value max_execution_time 60
# These set the user-specific paths
php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
php_value session.save_path /afs/example.com/home/smith/tmp
php_value upload_tmp_dir /afs/example.com/home/smith/tmp
그러나 사용자가 open_basedir을 변경하지 못하도록 .htaccess 파일에 올바른 권한을 설정했는지 확인하십시오 (subdir / .htaccess에서 재정의하려고 시도하면 작동하지 않아야하지만 아마도 테스트해야합니다) .
HTH
씨.
답변
AFS는 단순한 유닉스 사용자 권한을 무시합니다. suPHP는 PHP 프로그램을 실행하기 전에 setuid를 실행하지만 AFS에 액세스하는 데 필요한 Kerberos 토큰을 프로세스에 제공하지 않으며 권한으로 제한되지 않습니다. suPHP는 토큰을 획득하기 위해 어떤 방식 으로든 사용자로서 AFS 시스템에 자신을 표시하기 위해 수정되어야합니다. 내가 아는 한, 그것은 이루어지지 않았습니다. (사실, 나는 다른 사람이 그렇게했는지를 볼 때이 질문을 발견했습니다.)