Ostatnio stworzyłem zaszyfrowany system plików ( crypto_LUKS), który służy jako $ HOME tylko dla jednego konkretnego użytkownika (tzn. Montuję go jako /home/pduck). Dodałem również odpowiedni wpis, /etc/security/pam_mount.conf.xmlaby partycja została automatycznie odszyfrowana i zamontowana, gdy użytkownik się zaloguje (i odmontowana, gdy się wyloguje). Działa świetnie.
Ponieważ $ HOME jest systemem plików samodzielnie, użytkownik ma w nim lost+foundkatalog należący do root: root. Wiem, że usunięcie katalogu to zły pomysł, ale wiele poleceń (np. find) Narzeka na brak dostępu. To mnie denerwuje.
Z ciekawości usunąłem katalog i odtworzyłem go mklost+found(bez sudo). Teraz katalog jest własnością pduck: pduck. Czy to w porządku, czy ważne jest, aby katalog był własnością root: root?
źródło
2>/dev/nullktóry wycisza te komunikaty o błędach. Jeśli umieścisz go na początku, nie będzie to kolidować z argumentami, które chcesz przekazać w każdym wywołaniu.Odpowiedzi:
Dobra rada ma uzasadnienie, dzięki któremu można stwierdzić, kiedy stanie się złą radą.
Celem
lost+foundjest root jest tak, że bez względu na to, którego plik to było, co zostało utracone To nie nagle wystawione na każdego. Jednak w tym przypadku nie powinno być jednego pliku w całym systemie plików *, który nie jest własnością pduck; dlatego nie ma wady, żelost+foundnie należy do pduck.* z wyjątkiem egzotycznych sytuacji, takich jak pducking
sudo rootowania i uruchamianie aplikacji X. Ale jeśli pduck może użyćsudolubsunie mówimy o niczym, ponieważ pduck może całkowicie złamać bezpieczeństwo systemu.źródło
lost+foundto katalog systemowy i unikam manipulowania własnością i uprawnieniami do katalogów i plików systemowych.Istnieją inne katalogi (i pliki), które
findnarzekają, chyba że podniosę uprawnienia wiersza poleceń, więc sugeruję, abyś używałi wyjdź
lost+foundtak jak jest {is / powinno być}.źródło
mklost+foundpolecenie, aby je utworzyć i tworzy je z moją własnością. Może to po prostu okropnie napisane polecenie, które nie sprawdza$UID!=0;-) Poza tym nie podoba mi się pomysł bycia zmuszonym (mniej więcej) do używaniasudow moim własnym $ HOME.lost+foundjest bardzo stary, myślę, że od wczesnych dni UNIX-a i tak naprawdę nie wiem, kiedy jest używany w dzisiejszych czasach. Myślę jednak, że dobrą ogólną polityką jest unikanie manipulacji własnością i uprawnieniami do katalogów i plików systemowych (chyba że naprawdę wiesz, co może się stać za sceną).fsckumieszcza tam plików, gdy napotka „zagubione” pliki? Chodzi o to, żefsckma już miejsce, w którym można umieścić pliki (zamiast najpierw je utworzyć). Zauważ, żelost+foundzajmuje więcej miejsca (16384 bajtów) niż zwykły pusty katalog (4096 bajtów).chkdskjak w przypadku utraconych plików w MSDOS), ale rzadko widywałem tam jakiekolwiek dane w systemie Linux. Może kronikowanie może przywrócić pliki tam, gdzie były wcześniej, więc nie trzeba ich odwiedzaćlost+found. - Nawiasem mówiąc, mamlost+foundkatalog w/home, ale nie w moim katalogu domowym/home/sudodus, więc nie przeszkadza mi to./homemam innyl+f(też mi to nie przeszkadza), ponieważ/homei/home/pducksą osobnymi partycjami na moim komputerze. Ten drugi jest zaszyfrowany, drugi nie. Jednak gdy denerwuje mnie to zbyt mocno, mogę zamontować mój $ HOME gdzieś indziej i powiązać go z moim rzeczywistym $ HOME (jak na przykład tutaj nakreśliłem ), aby całkowicie pozbyć sięl+fw moim $ HOME. /// Usunę moje komentarze za kilka minut / godzin, aby uniknąć ostrzeżenia „przedłużona dyskusja… przejdź do czatu” .Nie ma nic naprawdę magicznego w katalogu lost + found. Jest to zwykły katalog, jak każdy inny i służy tylko do przechowywania utraconych plików / katalogów znalezionych podczas fsck po awarii systemu lub uszkodzeniu systemu plików.
Jest tworzony podczas mkfs, kiedy system plików jest tworzony i zwykle jest pusty. Jedynym powodem domyślnych uprawnień jest uniknięcie, aby poufne pliki były widoczne dla zwykłych użytkowników, jeśli zostaną znalezione i odzyskane podczas fsck. W epoce współczesnej rzadko gubi się pliki i umieszcza je w tym folderze.
Jeśli zostanie usunięty, uważam, że fsck odtworzy go w razie potrzeby, jeśli będą jakieś pliki, które trzeba tam umieścić. Ponieważ jest to system plików dla jednego użytkownika i jego samych danych, bez potrzeby ukrywania danych przed wścibskimi oczami, nie widzę powodu, dla którego uprawnień nie można zmienić na, powiedzmy, 755, aby zapobiec znalezieniu skargi lub zmianie własność. Możliwe, że fsck zresetuje swoje uprawnienia podczas procesu odzyskiwania, ale jest to rzadkie zdarzenie w nowoczesnym systemie plików, chyba że nastąpi poważna awaria sprzętu.
Jeśli chodzi o samo usunięcie, uważam, że cała paranoja oparta jest na fakcie, że fsck najlepiej jest zrobić tak mało, jak to możliwe, aby odzyskać dane, ale nie sądzę, żeby to naprawdę miało duże znaczenie w praktyce.
źródło