`chown user : user lost + found`는 유해합니까?

최근에 crypto_LUKS한 명의 특정 사용자에 대해서만 $ HOME 역할을 하는 암호화 된 파일 시스템 ( )을 만들었습니다 (예 :로 마운트 /home/pduck). 또한 /etc/security/pam_mount.conf.xml사용자가 로그인 할 때 파티션이 자동으로 해독 및 마운트되도록 (및 로그 오프 할 때 마운트 해제) 적절한 항목을 추가했습니다 . 잘 작동합니다.

$ HOME은 자체적으로 파일 시스템이므로 사용자는 lost+foundroot : root가 소유 한 디렉토리를 가지고 있습니다. 디렉토리 를 삭제 하는 것은 나쁜 생각 이지만 많은 명령 (예 find:)은 액세스 권한이 없음에 대해 불평합니다. 그것은 나를 귀찮게한다.

호기심으로 디렉토리를 제거하고 mklost+found(없이 sudo) 다시 만들었습니다 . 이제 디렉토리는 pduck : pduck이 소유합니다. 괜찮습니까? 아니면 루트 : 루트가 디렉토리를 소유해야합니까?

— 펄덕
소스

모든 파일 시스템에 lost + found 디렉토리가있는 것은 아닙니다. Ext4는 XFS는 그렇지 않습니다.

— jornane

답은 아니지만, 2>/dev/null오류 메시지를 끄는 것으로 시작하는 찾기 (바람직하게는 다른 이름으로)를위한 스크립트 또는 별명을 작성할 수 있습니다 . 처음에 넣으면 각 호출에서 찾기 위해 전달하려는 인수를 방해하지 않습니다.

— Joe

답변:

좋은 조언은 근거가되므로 나쁜 조언이 될 때 알 수 있습니다.

lost+found루트가 소유 한 목적은 파일이 손실 된 파일에 관계없이 모든 사람에게 갑자기 노출되지 않도록하는 것입니다. 그러나이 경우 pduck이 소유하지 않은 전체 파일 시스템 *에 단일 파일이 없어야합니다. 따라서 lost+foundpduck이 소유하지 않은 단점은 없습니다 .

* su뿌리를 내리고 X 응용 프로그램을 실행하는 것과 같은 이국적인 상황을 피하십시오 . 그러나 pduck이 사용할 수 sudo있거나 su우리가 아무 말도하지 않는다면 pduck은 시스템 보안을 완전히 파괴 할 수 있기 때문입니다.

— 여호수아
소스

lost+found 시스템 디렉토리이므로 시스템 디렉토리 및 파일의 소유권 및 권한을 변경하지 않습니다.

find커맨드 라인의 권한을 높이 지 않는 한 불평 하는 다른 디렉토리 (및 파일)가 있으므로 사용하는 것이 좋습니다.

sudo find ...

lost+found{있는 그대로 있어야합니다}.

— 스 도두
소스

예, 그렇게 생각했지만 OTOH는 mklost+found그것을 만들라 는 명령이 있으며 내 소유로 만듭니다 . 어쩌면 $UID!=0;-) 확인하지 않는 끔찍한 명령 일 수도 sudo있습니다.

— PerlDuck

lost+found아주 오래된 것입니다. 유닉스 초기 시절부터 생각합니다. 요즘은 언제 사용되는지 모르겠습니다. 그러나 시스템 디렉토리와 파일의 소유권과 권한을 무단 변경하지 않는 것이 좋은 일반적인 정책이라고 생각합니다.

— sudodus

하지 않습니다 fsck이 파일을 "손실"가 발생하면 거기에 파일을 넣어? 아이디어는 fsck이미 파일을 생성하는 대신 파일을 넣을 장소 가 이미 있다는 것입니다 . lost+found일반 빈 디렉토리 (4096 바이트)보다 많은 공간 (16384 바이트) 을 차지합니다.

— PerlDuck

네, 적어도 원래 목적 ( chkdskMSDOS에서 파일을 잃어버린 것과 비슷한 ) 이었지만 리눅스에서 데이터를 본 적이 거의 없습니다. 저널링으로 파일을 이전 위치로 복원 할 수 있으므로로 이동할 필요가 없습니다 lost+found. - 그건 그렇고, 내가 가지고 lost+found있는 디렉토리를 /home홈 디렉토리에 있지만 /home/sudodus거기 귀찮게하지 않도록.

— sudodus

동의한다. 그리고에 /home내가 다른이 l+f있기 때문에 (중 귀찮게하지 않음) /home과 /home/pduck내 컴퓨터에 별도의 파티션이다. 후자는 암호화되고 전자는 암호화되지 않습니다. 그러나 나를 너무 귀찮게 할 때 $ HOME을 다른 곳에 마운트하고 내 $ HOME 에서 완전히 제거하기 위해 실제 $ HOME에 바인딩 마운트 할 수 있습니다 (예 : 여기 에 설명 된 것처럼 ) l+f. /// "확장 토론… 채팅으로 이동" 경고 를 피하기 위해 몇 분 / 시간 내에 의견을 삭제 합니다.

— PerlDuck

lost + found 디렉토리에 대한 마법은 없습니다. 다른 디렉토리와 마찬가지로 일반 디렉토리이며 시스템 충돌 또는 파일 시스템 손상 후 fsck 중에 발견 된 손실 된 파일 / 디렉토리를 보유하는 데만 사용됩니다.

파일 시스템이 작성 될 때 mkfs 중에 작성되며 일반적으로 비어 있습니다. 기본 권한의 유일한 이유는 fsck 중에 민감한 파일이 발견되어 복구되는 경우 일반 사용자에게 민감한 파일이 표시되지 않도록하기위한 것입니다. 현대에는 파일이 손실되어 해당 폴더에 저장되는 경우가 거의 없습니다.

그것이 제거되면, 거기에 넣어야 할 파일이 있으면 fsck가 필요에 따라 그것을 다시 만들 것이라고 생각합니다. 이것은 하나의 사용자와 그의 데이터만을위한 파일 시스템이므로 데이터를 숨기지 않아도 숨길 필요가 없으므로 찾기가 불만을 제기하거나 변경하는 것을 방지하기 위해 권한을 755로 변경할 수 없었습니다. 소유권. 복구 프로세스 중에 fsck가 권한을 재설정 할 수도 있지만 심각한 하드웨어 오류가없는 한 최신 파일 시스템에서는 드문 경우입니다.

그냥 제거하는 것에 관해서는, 주변의 모든 편집증이 fsck가 데이터를 복구하기 위해 가능한 한 최소한으로 수행하는 것이 가장 좋다는 사실에 기반한다고 생각하지만 실제로 실제로는 그다지 중요하지 않다고 생각합니다.

— 펭귄 359
소스