설치 권한을 거부하는 방법은 무엇입니까?

여기에는 사용자와 수퍼유저가 파일 시스템을 마운트하고, 마운트된 파일 시스템의 파일에 액세스하고, "원시" 장치의 데이터에 액세스하는 작업이 혼합되어 있습니다.

1. 파일 시스템 마운트

   root파일 시스템은 이를 호스팅하는 장치에 액세스할 수 있는 경우 항상 마운트될 수 있습니다. 커널이 이를 인식하면 액세스할 수 있습니다. 사용자는 항목의 옵션에서 참조되고 /etc/fstab그 중 하나에 파일 시스템 user이 포함된 경우에만 파일 시스템을 마운트할 수 있습니다(맨 페이지 읽기).usersmount(8)

2. 마운트된 파일 시스템의 파일에 액세스

   마찬가지로, 마운트된 파일 시스템의 모든 파일은 전통적으로 root항상 액세스 가능했습니다(물론 패치된 커널을 사용하지 않는 한). 사용자에게는 파일 권한이 적용됩니다.

3. 원시 장치의 데이터에 액세스합니다(예 /dev/sdaX: )

   위와 같은 파일입니다. 사용자는 일반적으로 원시 블록 장치에 액세스할 수 없지만 root액세스할 수 있습니다.

따라서 두 번째 시스템의 사용자가 첫 번째 운영 체제에서 사용하는 마운트된 파일 시스템의 데이터를 설치하거나 액세스하는 것을 방지하려면 /etc/fstab권한을 적절하게 편집하고 적용하십시오. 파일 시스템에 대한 권한은 사용자/그룹 이름이 아닌 UID/GID에 바인딩되어 있으므로 foo시스템 1의 사용자가 시스템 2의 사용자와 동일한 숫자 UID를 갖는 경우 bar파일에 대한 전체 액세스 권한을 갖습니다.

슈퍼유저도 파일 시스템에 액세스할 수 없도록 하려면 암호화가 유일한 방법입니다.

또는 첫 번째 시스템의 가상 머신에서 두 번째 시스템을 실행하여 원하는 하드 드라이브 부분에만 액세스할 수 있습니다. 베어 메탈에서 두 번째 설치를 부팅할 수 있기를 원하지 않는 한, 이와 /dev/sda3같이 설정하는 방법은 여러 가지가 있습니다. 이 경우 전체 가상 머신을 /dev/sda.

마지막 참고 사항(특히 모든 사용자가 단순히 명령을 추가하여 sudo모든 사용자가 관리자 권한으로 모든 것을 실행할 수 있도록 허용하여 구성을 손상시키는 Ubuntu 및 유사한 배포판 사용자의 경우) -sudo"sudo를 통한 접근"root잘못된 용어입니다. 일반적으로 (UID 0) 사용자와 관련된 권한 중 일부(또는 전부)가 있거나 없습니다. 를 통해 동일한 권한을 얻을 수 있습니다 su.

blah이는 sda3 설치가 루트인지 여부 에 따라 다릅니다 . 그렇지 않은 경우:

기본적으로 루트로만 설치할 수 있으므로 /etc/fstab확인해야 할 사항은 다음과 같습니다.

1. 플래그가 필요합니다 noauto(시작 시 설치하지 마세요).
2. 해당 플래그가 없어야 합니다 user(또는 사용자가 설치할 수 있음).

그가 루트이거나 루트 권한을 가지고 있거나 얻을 수 있는 경우:

그러면 상황은 더욱 곤란해집니다. 기본적으로 루트는 시스템에서 무엇이든 할 수 있습니다. 파티션이 있고 읽을 수 있는 경우 이를 방지할 직접적인 방법은 없습니다. 비록 당신이 할 수 있는 간접적인 일들이 있기는 하지만(할 수 있다면 그것은 대부분 당신의 상황에 달려 있습니다).

1. 당신은 할 수암호화 sda1그리고 sda2. 루트 파티션을 암호화하려면 일반적으로 몇 가지 추가 작업이 필요하지만 대부분의 배포판에서는 이를 지원합니다. 다음으로 시작해야 하는 키워드: luks. 암호화는 이러한 파티션이 파괴되는 것을 막지는 못하지만, 읽는 것을 막는 것은 아닙니다. 또한 물리적인 직접 액세스를 사용하면 모든 것을 막을 수는 없지만 괜찮을 수도 있다는 점을 언급해야 합니다.
2. 일부 가상 머신 솔루션에서는 sda3 설치를 사용할 수 있습니다. sda1/sda2 설치에서는 클라이언트 액세스만 제공하고 가상 머신에서는 직접 sda1/sda2 액세스를 거부하며 sda3은 가상 머신에서 실행됩니다. 가상 머신의 권한을 제한하는 경우(sda1/sda2의 루트), sda3의 루트라도 해당 권한이 제한됩니다.