Para aqueles de vocês que não estão familiarizados com os Windows Servers, aproveito para explicar a comparação. Quando um servidor Windows é solicitado a desligar ou reiniciar, a GUI solicita que o usuário forneça um motivo para a solicitação, que é registrada em um log de auditoria. (Isso é opcional para uma solicitação de reinicialização do PowerShell (linha de comando). Além disso, quando um Windows Server é iniciado sem ter um motivo para a reinicialização, ele solicita aos usuários com privilégios adequados um motivo para a reinicialização na próxima vez que fizerem logon no sistema .
Sua sugestão é possível - até certo ponto. Você teria que considerar o que deveria acontecer se um comando reboot fosse emitido a partir de uma tarefa agendada ou outro local onde nenhum usuário administrativo estivesse logado. Você também precisaria considerar até onde você gostaria de ir com o seu cenário - se você estivesse procurando fornecer uma trilha de auditoria simples ou alguém tão profundamente envolvido no sistema que fosse quase impossível ignorá-lo. Obviamente, haveria um aumento de custo com o último.
Uma maneira de lidar com isso é mover um comando como reboot para, digamos, reboot.bin . Em seguida, crie um script chamado reboot , que é solicitado por meio da GUI ou da linha de comando, pelo motivo necessário e outras informações. Isso seria escrito via syslog para um arquivo de log apropriado (talvez auth.log ). O processo pode ser repetido para seus outros comandos "protegidos". Observe que não haveria nada além de etiqueta para impedir que seus usuários privilegiados executassem o reboot.bin (etc.) real diretamente.
O molly-guard package implementa isso , executando uma série de scripts antes de executar o comando real.
Outra maneira de lidar com isso seria pegar o código-fonte dos comandos "protected" e estendê-los nativamente. Mais trabalho, e apenas um pouco mais difícil de contornar. (Lembre-se, não é difícil ignorar a caixa de diálogo de desligamento no Windows - basta usar a linha de comando).