Czy `chown user: user lost + found` szkodliwy?

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?

— PerlDuck
źródło

Nie wszystkie systemy plików mają katalog utracony + znaleziony. Ext4 tak, na przykład XFS.

— jornane

Nie odpowiedź, ale możesz po prostu utworzyć skrypt lub alias dla find (najlepiej o innej nazwie), który zaczyna się od, 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.

— Joe

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, że lost+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ć sudolub sunie mówimy o niczym, ponieważ pduck może całkowicie złamać bezpieczeństwo systemu.

— Jozuego
źródło

lost+found to 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ł

sudo find ...

i wyjdź lost+foundtak jak jest {is / powinno być}.

— sudodus
źródło

Tak, tak myślałem, ale OTOH ma takie 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żywania sudow moim własnym $ HOME.

— PerlDuck

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ą).

— sudodus

Nie fsckumieszcza tam plików, gdy napotka „zagubione” pliki? Chodzi o to, że fsckma już miejsce, w którym można umieścić pliki (zamiast najpierw je utworzyć). Zauważ, że lost+foundzajmuje więcej miejsca (16384 bajtów) niż zwykły pusty katalog (4096 bajtów).

— PerlDuck

Tak, przynajmniej taki był pierwotny cel (podobnie 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, mam lost+foundkatalog w /home, ale nie w moim katalogu domowym /home/sudodus, więc nie przeszkadza mi to.

— sudodus

Zgadzam się. I /homemam inny l+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” .

— PerlDuck

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.

— penguin359
źródło