Linux: tornar o encerramento não executável por segurança

Hoje eu desliguei uma máquina de produção por engano, porque pensei que estava na minha máquina local. Eu sei, erro iniciante :-(

Como solução para que isso não aconteça novamente, eu estava pensando em remover a permissão de execução do comando shutdown, pois a máquina deve estar sempre ligada.

Essa é uma boa ideia? Você consegue ver algum efeito colateral indesejado fazendo isso?

Cheers, Dan

Completamente outra abordagem para ser avisado de que você trabalha em máquinas de produção é marcar o terminal. Por exemplo, o user@machine:~#texto pode ser vermelho nas máquinas de produção, verde no desenvolvimento, etc. Aqui está um bom tutorial de como fazer isso: Prompt do Color Bash

O melhor conselho que posso dar é não fazer login como root, a menos que precise de acesso root e verifique se você tem uma senha root / sudo diferente em cada máquina.

Tornar o desligamento inacessível é uma opção, mas não é uma boa. Alias shutdownpara shutdown -ae touch /etc/shutdown.allowouchmod a-x /sbin/shutdown

Além disso, onde termina? Você também não permitirá a interrupção, a reinicialização e o init?

Alguns pontos a considerar:

1. O que você estava fazendo como raiz em um sistema de produção durante o tempo de produção? Configure seus sistemas para que você não precise ser root neles para o trabalho diário. Você nunca deve ser root em um sistema de produção sem uma boa razão.
2. Aprenda a lição importante. Quando você é root, deve verificar duas vezes antes de pressionar enter. SUDO não é proteção se você acabou de escrever sua senha para continuar, sem pensar. A coloração imediata, como mencionado por mkudlacek, é uma ferramenta muito útil para ajudar a garantir que você não esteja no sistema errado.
3. Não mexa com as ferramentas internas. É provável que interrompa as atualizações e deixará novas contratações insanas. Se você quiser alterar algo, use seu próprio arquivo de alias.

Não acho que mexer com as permissões shutdownseja o caminho para lidar com a situação. Basicamente, você acabou de aprender uma lição. Queixo para cima.

Eu fiz o mesmo tipo de coisa - obtendo longas cadeias de sessões ssh e depois mexendo com as rotas em uma das máquinas pelas quais fui submetido, me interrompendo. Eu estraguei uma solicitação de rsync, levando à destruição sistemática de um sistema do outro lado do mundo. Eu corri rm -rf / pathem um servidor de produção. (Naquela época, aprendi como as restaurações funcionavam.)

Então, muito mais velho e espero um pouco mais sábio, agora tenho regras estritas que me imponho.

• Todos os prompts raiz terminam com um #, independentemente de outras informações neles.
• Sempre que estou no prompt #, literalmente sento em minhas mãos antes de pressionar a tecla Enter.
• Se houver alguma dúvida sobre o que estou prestes a fazer ou onde realmente estou ou como cheguei lá, cancelo e recompô-lo novamente a partir de uma condição de início conhecida.
• Quando eu cometo um erro (e ainda os cometo, embora eles estejam ficando cada vez menos frequentes e mais obscuros com o passar do tempo), descubra imediatamente o que eu fiz, em quem impactou e confesse meus pecados a eles . Em seguida, largue todo o resto e desfaça a manta o mais rápido e o melhor que puder.

A natureza do meu trabalho exige que eu gaste muito tempo com muitas solicitações de raiz variadas, mas graças aos meus erros no passado, mantenho uma consciência situacional muito melhor do que quando comecei.

Se você estiver usando o Ubuntu, tente o Molly-guard. Como discutido nesta pergunta semelhante .

Depende, realmente. Você pode tentar apenas agrupar o comando, mas isso significa que, se você fizer atualizações ou upgrades que afetam esse executável, poderá esquecê-lo e fazer com que ele estrague uma atualização. Tocar com comandos de desligamento do sistema pode ser uma PITA, especialmente se você tiver novas contratações ou um substituto que acabe por não saber que você estava jogando com os binários do sistema.

Pessoalmente, gostaria de agrupar o comando em um script que identifique o sistema pelo nome e faça com que você confirme o que você realmente deseja fazer antes de executar o binário real ou que você deve digitar uma determinada sequência de letras para confirmar o desligamento antes de executar o binário. Isso deve dar uma pausa.

Você pode considerar configurar o prompt de comando para incluir o nome da máquina, pelo menos nos servidores. Isso pode ajudar a impedir que outros comandos sejam executados na máquina errada no futuro. É mais eficaz se os nomes das máquinas forem coloridos para destacá-los e você pode até usar o código de cores para identificar as funções do servidor.

Uma maneira é não usar sue / ou fazer login diretamente no root. Melhor fazer login diretamente na conta E ter uma senha diferente para roota máquina local e a chave ssh.

Obviamente, além de observar o prompt '#' vermelho.

Sim, remover o bit de execução no comando shutdown é a maneira mais simples e segura de impedir desligamentos acidentais, especialmente se você tiver um ambiente de área de trabalho como o KDE na máquina e desejar impedir desligamentos acidentais ao fazer logout.

Quanto às novas pessoas confusas, acho que a primeira coisa que elas farão será ls -l /sbin/shutdowndescobrir por que não funciona (especialmente se elas têm o bom hábito de preencher nomes de executáveis). Obviamente, você deve contar a eles sobre as alterações que você fez.

Para segurança extra, você pode adicionar uma linha para /etc/rc.localremover o bit de execução do comando shutdown, para não esquecer de redefini-lo após uma reinicialização.

você pode simplesmente remover / sbin / do caminho da raiz. Dessa forma, você precisa digitar o caminho completo para executá-lo e, geralmente, corrige acidentes.