O `usuário chown: usuário perdido + encontrado` é prejudicial?

Recentemente, criei um sistema de arquivos criptografado ( crypto_LUKS) que serve como $ HOME para apenas um usuário em particular (ou seja, eu o montei como /home/pduck). Também adicionei uma entrada apropriada /etc/security/pam_mount.conf.xmlpara que a partição seja descriptografada e montada automaticamente quando o usuário efetuar login (e desmontada quando efetuar logoff). Funciona bem.

Como o $ HOME é um sistema de arquivos por si só, o usuário possui um lost+founddiretório de propriedade root: root. Eu sei que excluir o diretório é uma má idéia, mas muitos comandos (por exemplo find) reclamam de não ter acesso. Isso me irrita.

Por curiosidade, removi o diretório e o recriei com mklost+found(sem sudo). Agora, o diretório pertence ao pduck: pduck. Está tudo bem ou é crucial que o diretório seja de propriedade de root: root?

— PerlDuck
fonte

Nem todos os sistemas de arquivos têm um diretório perdido + encontrado. Ext4, XFS, por exemplo.

— jornane 27/01

Não é uma resposta, mas você pode simplesmente criar um script ou um alias para localizar (de preferência com um nome diferente) que comece com um 2>/dev/nullque silencie essas mensagens de erro. Se você colocar no início, ele não interferirá nos argumentos que você deseja passar para encontrar em cada invocação.

— Joe

Respostas:

Um bom conselho vem com uma justificativa para que você possa saber quando se torna um mau conselho.

O objetivo de lost+foundpertencer ao root é para que, não importa de quem foi o arquivo perdido, ele não seja exposto repentinamente a todos. Entretanto, nesse caso, não deve haver um único arquivo no sistema de arquivos inteiro * que não seja de propriedade do pduck; portanto, não há desvantagem em lost+foundnão pertencer ao pduck.

* barrando situações exóticas como pducking supara root e executando um aplicativo X. Mas se o pduck pode usar sudoou suestamos falando de nada, porque o pduck pode prejudicar a segurança do sistema.

— Joshua
fonte

lost+found é um diretório do sistema e evito violar a propriedade e as permissões dos diretórios e arquivos do sistema.

Existem outros diretórios (e arquivos) que findreclamam, a menos que eu eleve as permissões da linha de comando, então sugiro que você use

sudo find ...

e deixe lost+foundcomo está {deve / deve estar}.

— sudodus
fonte

Sim, pensei, mas OTOH existe esse mklost+foundcomando para criá-lo e cria-o com minha propriedade. Talvez seja apenas um comando horrivelmente escrito que não verifica $UID!=0;-) Além disso, eu não gosto da ideia de ser forçado (mais ou menos) a usar sudono meu próprio $ HOME.

— PerlDuck 27/01/19

lost+foundé muito antigo, acho que desde os primeiros dias do UNIX, e realmente não sei quando é usado atualmente. Mas acho que é uma boa política geral evitar violações da propriedade e das permissões dos diretórios e arquivos do sistema (a menos que você realmente saiba o que pode acontecer nos bastidores).

— sudodus 27/01/19

Não fsckcoloca arquivos lá quando encontra arquivos "perdidos"? A idéia é que fsckjá existe um lugar para colocar os arquivos (em vez de primeiro criar um). Observe que lost+foundocupa mais espaço (16384 bytes) do que um diretório vazio comum (4096 bytes).

— PerlDuck 27/01/19

Sim, pelo menos esse era o objetivo original (semelhante ao que chkdskocorreu com os arquivos perdidos no MSDOS), mas raramente vejo algum dado no linux. Talvez o registro no diário possa restaurar os arquivos para onde estavam antes, portanto eles não precisam ir lost+found. - A propósito, eu tenho um lost+founddiretório /home, mas não no meu diretório pessoal /home/sudodus, por isso não me incomoda lá.

— sudodus 27/01/19

Concordo. E /homeeu tenho outro l+f(também não me incomoda) porque /homee /home/pducksão partições separadas na minha máquina. O último é criptografado, o primeiro não. No entanto, quando isso me incomoda muito, posso montar meu $ HOME em outro lugar e ligá-lo ao meu $ HOME real (como eu descrevi aqui , por exemplo) para me livrar completamente do l+fmeu $ HOME. /// Excluirei meus comentários em alguns minutos / horas para evitar o alerta de "discussão prolongada ... mudar para o bate-papo" .

— PerlDuck 27/01/19

Não há nada realmente mágico no diretório perdido + encontrado. É apenas um diretório simples como qualquer outro e é usado apenas para armazenar arquivos / diretórios perdidos encontrados durante um fsck após uma falha no sistema ou corrupção no sistema de arquivos.

Ele é criado durante o mkfs quando o sistema de arquivos é criado e normalmente está vazio. A única razão para as permissões padrão é evitar que arquivos confidenciais se tornem visíveis para usuários comuns, se forem encontrados e recuperados durante um fsck. Na era moderna, é raro ver os arquivos serem perdidos e colocados nessa pasta.

Se for removido, acredito que o fsck irá recriá-lo conforme necessário, se houver algum arquivo que precise ser colocado nele. Como este é um sistema de arquivos para um usuário e seus dados, sem a necessidade de manter os dados ocultos, não vejo razão para que as permissões não possam ser alteradas para, por exemplo, 755 para impedir que as queixas ou reclamações sejam alteradas. propriedade. É possível que o fsck possa redefinir suas permissões durante um processo de recuperação, mas esse é um evento raro em um sistema de arquivos moderno, a menos que haja uma falha grave de hardware.

Quanto a removê-lo, acredito que toda a paranóia existente se baseia no fato de que é melhor o fsck fazer o mínimo possível para recuperar dados, mas não acho que isso realmente importe muito na prática.

— penguin359
fonte