Não, como $XMLFILES estava vazio, tentou remover /* . Tudo o que podemos fazer é remover os arquivos do diretório raiz, que um usuário normal não deve ser capaz de criar em primeiro lugar.
Suponha que estou no diretório / home / userA
Existe um ambiente variável $ XMLFILES que aponta para / u / xml / xmlfiles. A variável de ambiente $ XMLFILES está no ambiente / perfil do usuárioA
Eu faço logon como userA, em seguida, 'su' no userB e faço cd em / home / userB / testdata.
Eu não percebi que eu era userB então eu emiti o comando
rm $XMLFILES/*
E de repente eu vejo isso
bash-3.00$ rm $XMLFILES/*
rm: /bin not removed: Permission denied
rm: /boot is a directory
rm: /cdrom is a directory
rm: /dev is a directory
rm: /devices is a directory
rm: /etc is a directory
rm: /export is a directory
rm: /home is a directory
rm: /kernel is a directory
rm: /lib is a directory
rm: /lost+found is a directory
rm: /mnt is a directory
rm: /net is a directory
rm: /noffprotect: override protection 644 (yes/no)? ^C
Eu pressionei [CTRL + C] assim que vi a mensagem de proteção de substituição. Eu acho que desde que $ XMLFILES era nulo porque eu estava logado como userB o comando que foi emitido era realmente
rm *
Agora, o que eu não entendo é por que ele tentou excluir tudo da pasta raiz? desde que eu estava em / home / userB, deveria ter apenas tentado apagar tudo no 'nível superior de' / home / userB '? o comando rm não era nem mesmo uma exclusão recursiva.
Considerando que o usuário em que eu estava conectado como não era o usuário root, isso causaria algum dano?
$ XMLFILES teria sido uma string vazia, então o que você teria realmente emitido teria sido
rm ""/*
que teria sido avaliado até
rm /*
É por isso que você precisa ser muito cuidadoso ao usar $ variáveis (isto é, verificar sua existência primeiro) em argumentos de linha de comando.