일반적인 PHP 설정이 불안정합니까?

나는 대학의 시스템 관리 부서에서 일하면서 아마도 흔한 일을 우연히 발견했지만 꽤 충격적이었습니다.

모든 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 스크립트 없음, 백틱으로 외부 명령 실행 등).

이와 같은 정책을 변경하면 많은 문제가 발생하고 사용자가 자신의 갈퀴를 잡고 우리를 쫓아 갈 수 있습니다 ... 설정 변경 방법에 대한 결정을 내리면 동료와 논의하고 업데이트 할 것입니다.

소유자의 uid로 PHP 스크립트를 실행하는 suphp를 사용할 수 있습니다.

http://www.suphp.org

내 제안은 ( 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 시스템에 자신을 표시하기 위해 수정되어야합니다. 내가 아는 한, 그것은 이루어지지 않았습니다. (사실, 나는 다른 사람이 그렇게했는지를 볼 때이 질문을 발견했습니다.)