자신의 시스템에서는 루트만 읽을 수 있는 디렉토리를 다른 사람의 시스템에서도 루트로 읽을 수 있습니다.

시스템의 물리적 보안이 손상된 경우 암호화만으로 데이터를 보호할 수 있습니다.

컴퓨터에 물리적으로 액세스할 수 있는 사용자는 시스템을 단일 사용자 모드로 부팅하여 컴퓨터에서 하드 드라이브를 추출하지 않고도 루트로 파일에 액세스하도록 선택할 수도 있습니다.

네, 그럴 거예요.

확실하게.

이 질문은 Linux에만 국한된 것이 아니라는 점에도 주목했습니다.

• 다른운영 체제는 온디스크 ACL 및 파일 시스템 권한을 따를 필요가 없습니다.별말씀을요.
• 첫째, 디스크 액세스는 운영 체제 자체의 파일 시스템 드라이버와 보안 메커니즘을 거칠 필요가 없습니다. 관련 파일 시스템 형식은 다음과 같습니다.mtools 패키지결국 가능합니다.

  사실 이것은 GNU Hurd에 파일 시스템과 중간 인증 서버를 위한 자체 변환기를 설정하는 연습일 뿐입니다.

• 아니면 다른 경우라도같은운영 체제만 적용됩니다.그들만의ACL에 대한 UID 및 GID와 디스크에 대한 권한입니다. 물론 UID 0은 모든 운영 체제에서 동일합니다.

세 번째 점은 Windows NT SID 모델과 Unix ID 모델의 유명한 차이점 중 하나입니다. 대부분의 SID, 심지어 로컬 관리자의 SID에도 컴퓨터 관련 부분이 포함되어 있습니다. 따라서 마이그레이션된 디스크 볼륨에는 머신 A의 로컬 관리자(S-1-5-21-)의 ACL이 포함됩니다.기계 A-500) 머신 B의 로컬 관리자(S-1-5-21-기계 B-500) 왜냐하면아이디가 다릅니다ACE의 온디스크 ID는 전역적으로 고유합니다. Unix 모델에서 UID 0은 모든 시스템의 디스크에 있는 동일한 번호이며 단일 시스템에서만 로컬로 고유합니다.

(흥미롭게도 TrustedInstaller 사용자의 SID는 최신 Windows NT 시스템의 많은 운영 체제 파일에 대한 전체 액세스 권한을 갖습니다.예세계에서 유일합니다. 또한 흥미로운 점은 도메인 SID가 단일 공유 시스템 특정 부분을 가짐으로써 작동한다는 것입니다. )

따라서 인스턴스 간에 디스크를 이동할 수 있습니다.같은Windows NT의 경우 운영 체제는 다른 컴퓨터의 ACL을 자체 사용자 및 그룹으로 처리하지 않고 존중합니다. 그러나 다른 두 가지 사항은 여전히 ​​​​적용됩니다.

그래서:

다른 컴퓨터(자신의 컴퓨터도 포함)에서 동일한 운영 체제나 다른 운영 체제를 사용하여 내용을 읽을 수 없는 볼륨을 생성하려면 암호화를 사용하십시오.

기본 Unix 인증 메커니즘(ACL, MAC 등 확장이 로드되지 않은 상태)을 가정하면 특정 숫자 UID가 소유한 모든 권한은 파일 시스템이 마운트된 시스템에 관계없이 존재하게 됩니다. 루트 사용자는 실제로 항상 UID 0이므로(일부 외국 시스템에서는 다를 수 있지만 모든 경우에 모든 것에서 "uid || do _privileged_stuff();"를 가져와야 함;)) 이러한 권한이 전송됩니다. 서로 다른 UID를 가진 서로 다른 시스템에 동일한 사용자가 있는 경우 상황은 훨씬 더 혼란스럽습니다. 유닉스 커널은 단순히 사용자 이름을 모르거나 신경 쓰지 않습니다. 그들에게 당신은 숫자이고 당신이 자유인인지 아닌지는 아무것도 아닙니다. 그들의 사업가의. 사용자 이름과 UID를 함께 바인딩하는 것은 로그인과 관련된 사용자 공간 소프트웨어(getty, login, pam 등)의 작업이고, 이들을 함께 바인딩하는 것은 libc 및 파서 소프트웨어의 작업입니다.