Início / unix / Perguntas / 454694
Accepted
Raphael
Asked: 2018-07-12 04:57:51 +0800 CST

Como posso proteger scripts bash contra causar danos quando alterados no futuro?

  • 772

Então, apaguei minha pasta pessoal (ou, mais precisamente, todos os arquivos aos quais eu tinha acesso de gravação). O que aconteceu é que eu tinha

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

em um script bash e, depois de não precisar mais $build, removendo a declaração e todos os seus usos - mas o rm. Bash felizmente se expande para rm -rf /*. Sim.

Eu me senti estúpido, instalei o backup, refiz o trabalho que perdi. Tentando superar a vergonha.

Agora, eu me pergunto: quais são as técnicas para escrever scripts bash para que tais erros não aconteçam, ou pelo menos sejam menos prováveis? Por exemplo, se eu tivesse escrito

FileUtils.rm_rf("#{build}/*")

em um script Ruby, o intérprete teria reclamado por buildnão ter sido declarado, então aí a linguagem me protege.

O que considerei no bash, além de encurralar rm(o que, como muitas respostas em perguntas relacionadas mencionam, não é isento de problemas):

  1. rm -rf "./${build}/"*
    Isso teria matado meu trabalho atual (um repositório Git), mas nada mais.
  2. Uma variante/parametrização rmdisso requer interação ao atuar fora do diretório atual. (Não foi possível encontrar nenhum.) Efeito semelhante.

É isso ou existem outras maneiras de escrever scripts bash que são "robustos" nesse sentido?

bash shell-script

7 respostas

  1. Best Answer
    set -u

    ou

    set -o nounset

    Isso faria com que o shell atual tratasse as expansões de variáveis ​​não definidas como um erro:

    $ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

    set -ue set -o nounsetsão opções de shell POSIX .

    No entanto, um valor vazio não acionaria um erro.

    Para isso, utilize

    $ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

    A expansão de ${variable:?word}expandiria para o valor de variable, a menos que estivesse vazio ou não definido. Se estiver vazio ou não definido, o wordserá exibido em erro padrão e o shell tratará a expansão como um erro (o comando não será executado e, se estiver sendo executado em um shell não interativo, isso será encerrado). Deixar de :fora acionaria o erro apenas para um valor não definido, assim como em set -u.

    ${variable:?word}é uma expansão de parâmetro POSIX .

    Nenhum deles faria com que um shell interativo terminasse, a menos que set -e(ou set -o errexit) também estivesse em vigor. ${variable:?word}faz com que os scripts saiam se a variável estiver vazia ou não definida. set -ufaria com que um script fosse encerrado se usado junto com set -e.

    Quanto à sua segunda pergunta. Não há como limitar rmo trabalho fora do diretório atual.

    A implementação GNU de rmtem uma --one-file-systemopção que a impede de excluir recursivamente os sistemas de arquivos montados, mas isso é o mais próximo que acredito que podemos obter sem envolver a rmchamada em uma função que realmente verifica os argumentos.

    Como uma nota lateral: ${build}é exatamente equivalente a , a $buildmenos que a expansão ocorra como parte de uma string em que o caractere imediatamente seguinte seja um caractere válido em um nome de variável, como em "${build}x".

    • 78

  2. Vou sugerir verificações de validação normais usando test/[ ]

    Você estaria seguro se tivesse escrito seu script como tal:

    build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

    As [ -n "${build}" ]verificações que "${build}"é uma string de comprimento diferente de zero .

    O ||é o operador OR lógico no bash. Faz com que outro comando seja executado se o primeiro falhar.

    Desta forma, ${build}estava vazio/indefinido/etc. o script teria saído (com um código de retorno de 1, que é um erro genérico).

    Isso também o protegeria caso você removesse todos os usos , ${build}porque [ -n "" ]sempre será falso.

    A vantagem de usar test/ [ ]é que existem muitas outras verificações mais significativas que ele também pode usar.

    Por exemplo:

    [ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.
    • 12

  3. No seu caso específico, eu reformulei 'exclusão' no passado para mover arquivos/diretórios (assumindo que /tmp está na mesma partição que seu diretório):

    # mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

    Nos bastidores, isso move as referências de arquivo/diretório de nível superior da origem para as $trashdirestruturas de diretório de destino, todas na mesma partição, e não gasta tempo percorrendo a estrutura de diretório e liberando os blocos de disco por arquivo ali mesmo. Isso produz uma limpeza muito mais rápida enquanto o sistema está em uso ativo, em troca de uma reinicialização um pouco mais lenta (/tmp é limpo nas reinicializações).

    Alternativamente, uma entrada cron para limpar periodicamente /tmp/.trash-$USER impedirá que /tmp seja preenchido, para processos (por exemplo, compilações) que consomem muito espaço em disco. Se seu diretório estiver em uma partição diferente como /tmp, você pode criar um diretório semelhante a /tmp em sua partição e fazer com que o cron limpe isso.

    Mais importante, porém, se você estragar as variáveis ​​de alguma forma, você pode recuperar o conteúdo antes que a limpeza aconteça.

    • 4

  4. Use a substituição de parâmetro bash para atribuir padrões quando a variável não for inicializada, por exemplo:

    rm -rf ${variável:-"/inexistente"}

    • 2

  5. Eu sempre tento iniciar meus scripts Bash com uma linha #!/bin/bash -ue.

    -esignifica "falha no primeiro erro não detectado ";

    -usignifica "falha no primeiro uso da variável não declarada".

    Encontre mais detalhes no ótimo artigo Use o Unofficial Bash Strict Mode (a menos que você adore a depuração) . Também o autor recomenda o uso set -o pipefail; IFS=$'\n\t', mas para meus propósitos isso é um exagero.

    • 1

  6. O conselho geral para verificar se sua variável está definida é uma ferramenta útil para evitar esse tipo de problema. Mas neste caso havia uma solução mais simples.

    Provavelmente, não há necessidade de glob o conteúdo do $builddiretório para excluí-los, mas não o próprio $builddiretório real. Portanto, se você pulou o estranho *, um valor não definido se transformaria no rm -rf /qual, por padrão, a maioria das implementações de rm na última década se recusará a executar (a menos que você desative essa proteção com a --no-preserve-rootopção do GNU rm).

    Ignorar o trailing /também resultaria na rm ''mensagem de erro:

    rm: can't remove '': No such file or directory

    Isso funciona mesmo que seu comando rm não implemente proteção para arquivos /.

    • 1

  7. Você está pensando em termos de linguagem de programação, mas bash é uma linguagem de script :-) Então, use um paradigma de instrução totalmente diferente para um paradigma de linguagem totalmente diferente .

    Nesse caso:

    rmdir ${build}

    Como rmdirse recusará a remover um diretório não vazio, você precisa remover os membros primeiro. Você sabe quais são esses membros, certo? Eles provavelmente são parâmetros para seu script ou derivados de um parâmetro, então:

    rm -rf ${build}/${parameter}
rmdir ${build}

    Agora, se você colocar alguns outros arquivos ou diretórios lá, como um arquivo temporário ou algo que você não deveria, rmdirele gerará um erro. Trate-o corretamente, então:

    rmdir ${build} || build_dir_not_empty "${build}"

    Essa maneira de pensar me serviu bem porque... sim, estive lá, fiz isso.

    • -3

relate perguntas