Permissões de arquivo em backups de dados

Question

Depois de cometer um erro relacionado a rm em alguns dos meus arquivos (o que foi bom porque eu tenho backups), comecei a pensar em como eu poderia me limitar a cometer tais erros. Eu não fiz nada com permissões de arquivo, então comecei a ler sobre isso, mas acho que talvez esteja faltando alguma coisa. Eu essencialmente gostaria de definir meus backups de dados (um: um disco rígido externo Windows NT Filesystem; dois: um servidor baseado em UNIX, mas eu não sei os detalhes exatos dele) para que quando eu iria tentar remover ou não manipular meus arquivos, eu não seria capaz de fazê-lo sem sudo ou alguma outra substituição, ou obter algum tipo de "você tem certeza?" - prompt. Ou talvez haja algum tipo de permissão de arquivo "padrão" para backups de dados que as pessoas usam e que são melhores do que eu estou pensando?

Eu tenho jogado um pouco com chmod e várias configurações, mas não consigo acertar. Tanto quanto eu entendo, 755 parece ser o tipo de padrão, mas tanto quanto eu entendo que não iria me impedir de fazer o tipo de erros que eu fiz. E quanto a 555 ? Você deve configurar pastas de maneira diferente dos seus arquivos? O que as pessoas geralmente usam para proteger seu armazenamento de longo prazo, ou seja, arquivos que você não acessa com frequência?

    

Answer 1

Se você remover o bit 'w', não poderá sobrescrever acidentalmente o que quer que tenha removido o bit 'w'. Se for um diretório, isso significa que você não pode adicionar ou remover arquivos desse diretório; se é um arquivo, isso significa que você não pode alterar o arquivo. A desvantagem desse método, no entanto, é que você perde dados (IMO, as permissões de arquivo fazem parte dos seus dados de backup).

Uma alternativa é usar o atributo estendido "imutável":

chattr +i file_or_directory

O lado negativo do método é que pode ser confuso: ls -l diz que você pode escrever no arquivo, mas se você tentar o kernel diz 'permissão negada', mesmo como root; você precisa lembrar dos atributos estendidos (que lsattr pode lhe informar)

Em seu comentário final: a melhor maneira de evitar a alteração acidental de arquivos, que você não precisa acessar com frequência, é simplesmente não disponibilizá-los para uso normal. Não monte automaticamente o sistema de arquivos; faça com que a etapa mount faça parte de seu procedimento de backup. Se você fizer isso, todos esses problemas desaparecem.

    

Answer 2

Em geral, ele evitaria todo o sudo e deliberadamente inibiria o acesso a seus arquivos - provavelmente causaria problemas e possivelmente seria tão irritante que você simplesmente substituiria seus próprios mecanismos de proteção de qualquer maneira.

Em vez disso, usaria trash-cli , que se comporta como uma lixeira do tipo desktop, na qual você pode recuperar o arquivo mais tarde, se cometer um erro.
Se você está usando o gerenciador de pacotes APT você pode instalar com

apt-get install trash-cli

Ou use yum ou pacman , seja qual for o seu gerenciador de pacotes, basicamente, basta substituir o comando rm pelo comando trash . Então você pode enlouquecer a exclusão de seus arquivos e não ter que se preocupar com a perda de dados, porque você pode recuperar seus arquivos mais tarde.
Se você usar verbose, por exemplo, trash -v <file> trash-cli listará o diretório para o qual está lixando os arquivos.

    

Answer 3

A alteração das permissões dos diretórios para 555 (ou 550 ou 500 ...) impedirá a exclusão ou a criação de arquivos dentro deles. Alterar as permissões dos arquivos para 444 impedirá que você os modifique. (Você realmente precisa combinar ambas as operações, já que muitos editores criarão um novo arquivo ao "modificar" um existente, o que efetivamente significa que você pode acabar modificando um arquivo somente leitura se você puder escrever no diretório pai.)

A opção mais segura para evitar modificações indesejadas em arquivos ou diretórios é torná-los imutáveis:

chattr -R +i .

protegerá recursivamente todos os diretórios e arquivos a partir do diretório atual. Para tornar um arquivo modificável novamente,

chattr -i file

Você precisa ser root para realizar uma dessas operações.

lsattr mostrará os atributos atuais dos diretórios e arquivos.

    

Answer 4

E os aliases? Digitando alias na linha de comando, você verá todos os aliases definidos. Sugiro adicionar algo como:

alias rm='rm -i'

Defina-o em ~ / .bashrc, (para que você possa removê-lo no futuro ou alterá-lo para atender às suas necessidades.)

[mal@localhost ~]$ touch 123
[mal@localhost ~]$ rm 123
[mal@localhost ~]$ touch 123
[mal@localhost ~]$ rm -i 123
rm: remove regular empty file ‘123’? y
[mal@localhost ~]$ 

OR

Aqui está mais um truque.

Crie um arquivo chamado -i nesse diretório usando touch -- -i ou touch ./-i

Agora, tente rm -rf * :

[mal@localhost stack]$ touch {1..10}
[mal@localhost stack]$ touch -- -i
[mal@localhost stack]$ ls
1  10  2  3  4  5  6  7  8  9  -i
[mal@localhost stack]$ rm -rf *
rm: remove regular empty file ‘1’? n
rm: remove regular empty file ‘10’? n
rm: remove regular empty file ‘2’? n

Aqui, o * expandirá -i para a linha de comando, de modo que seu comando se torne rm -rf -i . Este comando irá avisar antes da remoção.

OR

Use safe-rm

Safe-rm is a safety tool intended to prevent the accidental deletion of important files by replacing /bin/rm with a wrapper, which checks the given arguments against a configurable blacklist of files and directories that should never be removed.

Users who attempt to delete one of these protected files or directories will not be able to do so and will be shown a warning

message instead:

$ rm -rf /usr
Skipping /usr