apache2에서 encfs를 사용할 때 / etc / mtab에 마운트 지점이 없습니다.


2

encfs 암호화 폴더를 원격으로 마운트 할 수있는 웹 페이지를 작성했으며 WebDAV를 통해 액세스 할 수 있습니다. 기본적으로 마운트 / 마운트 해제 버튼이있는 비밀번호 양식입니다.이 버튼은 양식을 통해 제공된 비밀번호로 사전 정의 된 encfs 암호화 된 드라이브를 마운트 / 마운트 해제하려고합니다. 기본적으로 인터넷에 액세스 할 수있는 래퍼

encfs --stdinpass /encfs/drive/encrypted/ /var/www/unencrypted

암호화 된 드라이브를 마운트 / 마운트 해제 할 수 있고 WebDAV를 통해 암호화되지 않은 데이터를 보거나 읽을 수있는 것처럼 의도 한대로 작동합니다.

그러나 이상한 일이 있습니다. 암호화되지 않은 폴더의보기는 WebDAV를 통해서만 액세스 할 수 있습니다.

나는 실행하는 경우 는 sudo -u www가 데이터 LS는 -la의 / var / www가 (www가 데이터 따라서 웹 서버와를 실행하는 사용자입니다 또한 드라이브를 마운트 사용자가, 내가 htop이 확인했습니다) 또는 다른 사용자로, I 일반적인 encfs 폴더가 아닌 일반 폴더로 마운트 지점 (위의 예에서 / var / www / unencrypted)을 참조하십시오. 일반적으로 다음과 같습니다.

drwxr-xr-x  5 www-data www-data  4096 Feb  1 02:25 .
drwxr-xr-x 15 root     root      4096 Jan 31 11:46 ..
d?????????  ? ?        ?            ?            ? unencrypted

그러나 실제로는 다음과 같습니다.

drwxr-xr-x  5 www-data www-data  4096 Feb  1 02:25 .
drwxr-xr-x 15 root     root      4096 Jan 31 11:46 ..
drwxr-xr-x  2 www-data www-data  4096 Jan 31 21:47 unencrypted

일반 폴더처럼 (WebDAV를 통해 액세스 할 때 동일한 폴더에 데이터가 있지만 빈 폴더로보고 됨).

또한 / etc / mtab에는 encfs 드라이브가 마운트되었음을 ​​나타내는 항목이 없습니다. WebDAV를 통해 드라이브에 액세스 할 수 있으며 htop에 표시된 것처럼 ecnfs 프로세스가 명확하게 실행되기 때문에 모든 의도와 목적을 위해 드라이브가 마운트되지 않은 것처럼 보입니다.

어떻게 이런 일이 발생하고 어떻게 해결할 수 있습니까?

추신 : 내가 달리면

sudo -u www-data bash -c "echo $(cat /tmp/passwort_file) | encfs --stdinpass /encfs/drive/encrypted/ /var/www/unencrypted"

터미널에서 그러한 동작은 없습니다. 폴더는 여전히 WebDAV를 통해 액세스 할 수 있지만이 경우 / etc / mtab에도 올바르게 표시되며 ls -la를 사용할 때 encfs 드라이브로도 표시됩니다 .


테스트 명령이 마운트를 www-data (echo 만)로 실행한다고 생각하지 않습니다.
davidgo

당신은 옳습니다, sudo-u www-data는 파이프 이후의 모든 것이 아니라 에코에만 적용됩니다. 그러나 실제로는 전체 명령을 스크립트로 실행하므로 모든 것을 www-data로 실행해야합니다. 혼란을 드려 죄송합니다.이를 반영하기 위해 테스트 명령 예제를 변경하겠습니다.
luksen

답변:


1

서비스 관리자로 systemd 된 Debian Linux 또는 Ubuntu라고 가정합니다.

리눅스는 파일 시스템의 다른 뷰를 다른 프로세스에 제공하는 "마운트 네임 스페이스"를 지원합니다 (chroot와 같이 훨씬 유연하고 두통을 유발합니다). Systemd에서는이 기능을 사용하여 보안 문제 및 공격으로부터 시스템을 강화할 수 있습니다. 예를 들어, 특정 서비스는 / home을 비어 있거나 / etc를 읽기 전용으로 볼 수 있습니다.

대부분의 배포판은 apache2.service에서 다음 보안 설정을 사용합니다.를 실행 systemctl cat apache2하면 자체 개인 /tmp디렉토리 를 갖도록 구성되어 있습니다 .

[Service]
...
PrivateTmp=true

마운트 네임 스페이스의 부작용들이 다소 글로벌 걸입니다 : 한 번 systemd "공유 해제"가 /만들 수 있도록 아파치를 전용 단지 하나의 산을 필요로하는 경우에도, 아래에 장착, 같은 효과는 여전히 적용 모두 에 의해 생성 마운트 아파치 서비스. (서비스의 경우 이것은 어느 정도 의도적 인 것입니다. 왜 웹 서버가 실제로 파일 시스템을 마운트해야합니까? 최소한의 권한 원칙.)

그래서 당신은 실행하는 경우 findmnt또는 cat /proc/self/mounts당신은 단지 루트 네임 스페이스에 마운트를 볼 수 있습니다. 당신이 실행한다면 nsenter --mount --target <APACHE_PID> findmntcat /proc/<APACHE_PID>/mounts, 당신은 볼 둘 것이다 루트 네임 스페이스에서 상속하는, 아파치 프로세스 개인들.

이 보호 기능을 사용하지 않으려면, 실행 systemctl edit --full apache2및로 시작하는 모든 설정을 제거 Private*, ReadOnly*또는 Inaccessible*.


감사합니다. 이것이 정확히 문제임을 확인할 수 있습니다. 나는 apache2가 일종의 "보호 된 환경"에서 실행될 수 있을지 의심했지만이 "마운트 네임 스페이스"가 존재한다는 것을 몰랐습니다. 새로운 것을 배웠습니다. 이제이 보호 기능을 완전히 비활성화하는 것을 꺼려합니다. 이 하나의 명령 / 마운트 포인트에 대해서만 비활성화 할 수있는 방법이 있습니까?
luksen

nsenter를 읽은 후 nsenter --all --target 1 encfs [...]를 사용하면 루트 PID의 네임 스페이스를 입력하는 데 사용할 수 있음을 알았습니다. 이것으로 마운트 / 마운트 해제가 전 세계적으로 작동하지만 루트 PID의 네임 스페이스를 감지하는 것이 안전하지 않다고 생각합니까?
luksen

문제는 우선 루트 권한이 필요하다는 것입니다. 우선 sudo를 사용하는 것이 가능하지만 sudo 규칙을 작성할 때 매우 정확해야합니다. 와일드 카드.
grawity
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.