특정 목적(예: 데이터 파일 공유를 위한 드롭 포인트)을 위해 FTP 계정을 설정할 때 사용자에게 특정 디렉토리에 대한 액세스 권한만 부여하고 더 넓은 파일 시스템에 대한 보기는 제공하지 않는 것이 합리적으로 보입니다.
특히 *nix 시스템에서 모든 사용자는 일반적으로 /etc/passwd. FTP 데몬을 사용하면 일반적으로 로그인 시 실행하여 이를 숨길 수 있으므로 chroot사용자는 가상의 "감옥"에 있습니다.
하지만chroot보안 조치로 설계되지 않았습니다.[사이트가 다운된 것 같을 때 아카이브 사본], 그 자체로 보안 문제가 발생할 수도 있습니다. 이러한 이유로 vsftpd이 기능이 제한됨따라서 chroot읽기 전용 디렉터리로만 이동할 수 있으며, 사용자는 쓰기 작업을 수행하려면 하위 디렉터리로 이동해야 합니다.프로FTPD문제에 대해 경고하지만 대안을 제공하지 않으며 PureFTPD에서는 chroot.
제가 보기에는 FTP 액세스가 OS의 파일 시스템 액세스 개념과 매핑되는 근본적인 이유가 전혀 없는 것 같습니다. HTTP 데몬과 마찬가지로 FTP 데몬은 일련의 구성 규칙에 따라 모든 요청을 "다시 쓸" 수 있습니다. Apache 웹 호스트에 경로를 요청하면 해당 경로는 호스트 OS의 현재 디렉터리가 아닌 디렉터리 /에 정의된 디렉터리에 매핑됩니다 .DocumentRoot/
내 질문은 *nix FTP 데몬이 이와 같은 "다시 쓰기" 메커니즘(또는 액세스를 제한하는 다른 방법)을 사용합니까? 그렇지 않은 경우 근본적인 이유가 있습니까?
참고: 와 일부 중복되는 내용이 있습니다.이 기존 질문, 그러나 답변은 chroot완전한 대안보다는 주로 사용 여부에 대해 논의합니다.
답변1
http://www.ietf.org/rfc/rfc959.txt
사양에는 '대상'이나 서버 측이 특정 유형의 파일 시스템을 가리켜야 한다고 명시되어 있지 않다고 가정하겠습니다. 이에 대해 너무 깊이 읽지 않고도 합리적인 방법으로 사용자를 가두는 데몬을 작성하고 여전히 실행 가능하다고 생각합니다.
또는 selinux와 같은 기능을 사용하면 ftp 데몬을 변경하지 않고도 ftp 사용자를 특정 디렉터리로 제한할 수 있습니다.