Recentemente, me deparei com um cenário de alta disponibilidade em que o programa de manutenção precisa vincular um IP virtual ao servidor em que ele se encontra e, em seguida, transmiti-lo pela rede. Para fazer isso, ele executa ipe arpcomanda, respectivamente. No entanto, notei que qualquer programa de manutenção precisa sudoerde privilégio para executar ipou arp. Não dou o mesmo rootprivilégio a ele, mas quero que ele ainda seja capaz de executar esses dois comandos. Então, há uma solução? Desde já, obrigado.
O cenário HA requer o failover de um endereço IP (virtual) e o envio de solicitações arp gratuitas para garantir que a LAN saiba que ocorreu um failover IP.
Fazer alterações em uma pilha de IP do sistema e enviar solicitações arp gratuitas requer acesso privilegiado/nível raiz.
Quando as ferramentas que fazem essas alterações já são executadas como root, é claro que já existe acesso privilegiado suficiente.
Quando o conjunto de ferramentas não é executado como root, é necessário um método para conceder esse acesso privilegiado. Uma política sudoers é um método que pode conceder privilégios refinados.
Uma alternativa é, por exemplo, definir permissões de root set-uid nesses comandos, mas isso permite que todos e quaisquer usuários enviem solicitações arp gratuitas e modifiquem os caches ARP de sistemas vizinhos e/ou modifiquem a pilha IP dos sistemas. Isso é provavelmente menos desejável.
Isso é principalmente um comentário (mas não há espaço suficiente na caixa de comentários).
Existe uma solução para executar um comando que requer privilégios elevados sem elevar privilégios? - Não
"Eu não dou esse tipo de privilégio root" - Se você tivesse explicado suas reservas, poderíamos sugerir uma alternativa ou dissipar suas preocupações, por exemplo
permite que o usuário de 'manutenção' SOMENTE execute o script nomeado como root.
Mas estou lutando para imaginar um cenário em que um serviço para implementar alta disponibilidade exigiria uma inicialização manual. A execução como um serviço também oferece benefícios para garantir que o serviço continue em execução - então, por que não apenas provisioná-lo dessa maneira como o usuário root? Infelizmente, DROPPING privilégios de root requer ferramentas adicionais . Portanto, pode fazer mais sentido executar o serviço como um usuário não privilegiado com regras sudo para operações privilegiadas.
O Linux também possui um sistema de gerenciamento de privilégios descrito como capacidades - mas conceder capacidades para resolver este problema pode minar seu objetivo indefinido implícito por não usar a conta root.
Você pode permitir que um usuário execute comandos específicos e nada mais por meio do sudo como qualquer usuário (como a coisa "executar como" no Windows). Não há obrigação de fornecer acesso root completo, o sudo pode ser muito granular.
Leia o manual para sudoers.
Para o cenário HA, essa é mais ou menos a descrição do VRRP