`Chown user: user lost + found` è nocivo?

Di recente ho creato un filesystem crittografato ( crypto_LUKS) che funge da $ HOME per un solo utente (ovvero lo monto come /home/pduck). Ho anche aggiunto una voce appropriata in /etc/security/pam_mount.conf.xmlmodo che la partizione venga automaticamente decifrata e montata quando l'utente accede (e smonta quando si disconnette). Funziona alla grande.

Poiché $ HOME è un filesystem a sé stante, l'utente ha una lost+founddirectory di proprietà di root: root. So che eliminare la directory è una cattiva idea ma molti comandi (ad es. find) Si lamentano di non avere accesso. Questo mi infastidisce.

Per curiosità ho rimosso la directory e l'ho ricreata con mklost+found(senza sudo). Ora la directory è di proprietà di pduck: pduck. Va bene o è cruciale che la directory sia di proprietà di root: root?

— PerlDuck
fonte

Non tutti i file system hanno una directory lost + found. Ext4 lo fa, XFS no, per esempio.

— jornane,

Non una risposta, ma potresti semplicemente creare uno script o un alias per find (preferibilmente con un nome diverso) che inizia con un 2>/dev/nullche mette a tacere quei messaggi di errore. Se lo metti all'inizio, non interferirà con gli argomenti che vuoi passare per trovare in ogni invocazione.

— Joe

Risposte:

Un buon consiglio viene fornito con una logica in modo da poter dire quando diventa un cattivo consiglio.

Lo scopo di lost+foundessere di proprietà di root è in modo tale che, indipendentemente dal file perso, non sia improvvisamente esposto a tutti. Tuttavia, in questo caso, non dovrebbe esserci un singolo file nell'intero filesystem * non di proprietà di pduck; pertanto non vi è alcun lost+foundaspetto negativo a non essere di proprietà di pduck.

* salvo situazioni esotiche come il pduck suing su root e l'esecuzione di un'applicazione X. Ma se pduck può usare sudoo sudi questo non stiamo parlando di nulla perché pduck può rompere completamente la sicurezza del sistema.

— Giosuè
fonte

lost+found è una directory di sistema ed evito di manomettere la proprietà e le autorizzazioni delle directory e dei file di sistema.

Ci sono altre directory (e file) che si findlamentano, a meno che non elimini le autorizzazioni della riga di comando, quindi ti suggerisco di usare

sudo find ...

e lascia lost+foundcome è {dovrebbe / dovrebbe essere}.

— sudodus
fonte

Sì, così ho pensato, ma OTOH c'è quel mklost+foundcomando per crearlo e lo crea con la mia proprietà. Forse è solo un comando orribilmente scritto che non verifica la presenza di $UID!=0;-) Inoltre, non mi piace l'idea di essere costretto (più o meno) a usare sudonella mia stessa $ HOME.

— PerlDuck,

lost+foundè molto vecchio, penso dai primi giorni di UNIX, e non so davvero quando viene usato al giorno d'oggi. Ma penso che sia una buona politica generale evitare di manomettere la proprietà e le autorizzazioni delle directory e dei file di sistema (a meno che tu non sappia davvero cosa può accadere dietro la scena).

— sudodus,

Non fsckinserisce i file quando incontra file "persi"? L'idea è che fsckabbia già un posto dove mettere i file (invece di crearne uno per primo). Si noti che lost+foundoccupa più spazio (16384 byte) di una normale directory vuota (4096 byte).

— PerlDuck,

Sì, almeno quello era lo scopo originale (simile a quello chkdskfatto con i file persi in MSDOS), ma raramente ho mai visto alcun dato lì su Linux. Forse l'inserimento nel journal può ripristinare i file dove erano prima, quindi non è necessario andare a lost+found. - A proposito, ho una lost+founddirectory dentro /home, ma non nella mia directory home /home/sudodus, quindi non mi dà fastidio lì.

— sudodus,

Sono d'accordo. E ne /homeho un altro l+f(non mi disturba neanche) perché /homee /home/pducksono partizioni separate sulla mia macchina. Quest'ultimo è crittografato, il primo no. Tuttavia, quando mi dà troppo fastidio, posso montare $ HOME da qualche altra parte e collegarlo alla mia $ HOME effettiva (come ho delineato qui , per esempio) per liberarmi completamente da l+f$ HOME. /// Eliminerò i miei commenti tra un paio di minuti / ore per evitare l' avviso "discussione estesa ... passa alla chat" .

— PerlDuck,

Non c'è nulla di veramente magico nella directory lost + found. È solo una directory semplice come qualsiasi altra e viene utilizzata solo per contenere file / directory persi trovati durante un fsck dopo un crash del sistema o una corruzione del file system.

Viene creato durante mkfs quando viene creato il file system ed è normalmente vuoto. L'unico motivo delle autorizzazioni predefinite è evitare che i file sensibili diventino visibili agli utenti normali se vengono trovati e ripristinati durante un fsck. Nell'era moderna è raro vedere i file perdersi e metterli in quella cartella.

Se viene rimosso, credo che fsck lo ricrea quando necessario, se ci sono dei file che devono essere messi lì. Poiché si tratta di un file system per un utente e i suoi dati da soli senza la necessità di mantenere i dati nascosti da occhi indiscreti, non vedo alcun motivo per cui le autorizzazioni non possano essere cambiate in, diciamo, 755 per evitare che si ritrovino a lamentarsi o a cambiare Proprietà. È possibile che fsck ripristini le autorizzazioni durante un processo di recupero, ma questo è un evento raro su un moderno file system a meno che non si verifichino gravi guasti hardware.

Per quanto riguarda solo la sua rimozione, credo che tutta la paranoia intorno sia basata sul fatto che è meglio fare fsck il meno possibile per recuperare i dati, ma non penso che contenga davvero molto nella pratica.

— penguin359
fonte