Scripts que precisam de (alguns) acesso root

Question

Eu tenho uma pergunta geral sobre scripts de administração do sistema que requerem que alguns comandos sejam executados com acesso root, e outros como um usuário não-root normal (ie myusername, etc.). Eu devo mencionar que estou usando o Ruby 1.8.6 em um sistema Linux Red Hat 4. As sugestões que vi até agora são:

1. Permitir acesso de sudoers:
     USERNAME = NOPASSWD: / caminho / para / script, /etc/init.d/httpd, / caminho / para / algoelse
     Esta sintaxe está correta? Em caso afirmativo, estou certo de que gostaria de listar todos os comandos específicos necessários no script em que eu não queria que a senha fosse solicitada?
   
   
2. Definir suid
   link
     Para executar um script Perl com privilégio de root:
     a) Defina o proprietário do script como root
     b) Defina o bit suid no arquivo em (chmod u + s filename)
     c) Desative a permissão de leitura e execute a permissão para o arquivo para todos, exceto root (chmod go = x)
     Mas outra pesquisa sugere que você só pode definir suid em binários para sistemas Linux posteriores (meu script será executado em uma versão antiga do RH4, mas podemos acabar atualizando para que eu queira ser compatível com versões futuras). Eu não acho que quero criar um binário apenas para isso!
   
   
3. 'Use ssh com chaves públicas / privadas geradas. A chave pode ser configurada para permitir que apenas certos comandos sejam executados com ela. '
   
   
4. Deixar no sudo qualquer comando com script que exija raiz:
     sistema 'sudo rake ts: reconstruir' (claro que isso tem a desvantagem de ter todos os prompts de senha!)
   
   
5. Executar script como root
     Mas e os comandos que quero executar como um usuário normal?
   
   
6. Executar como usuário root su (para tarefas que precisam ser executadas como o usuário normal)
   'Executar script como root, fazer um monte de tarefas como root, su newUser fazer um monte de tarefas como newUser, sair (sai de volta para o usuário root) fazer um monte de mais tarefas como root.' (proposto por James abaixo)
   

Eu me sinto envergonhado por não ter uma melhor compreensão deste tópico, mas estou um pouco surpreso com quantos Ruby "scripting books" eu me referi que não tratam disso! Eu acho que é mais uma coisa "nix", mas parece que para fazer qualquer coisa de uso substancial, você provavelmente se depararia com isso.

Edit: Algumas coisas como mysql eu posso usar opções no comando como - password então eu usei isso para fazer isso:

puts "Remote Password: "
system('stty -echo')
password = STDIN.gets.chomp
puts "Mysql Password (local): "
mysql_local_password = STDIN.gets.chomp
system('stty echo')

E então eu posso usar essas senhas de dentro do script, mas elas nunca são vistas como texto claro. Mas isso não funciona para tudo, claro.

A outra coisa que devo mencionar é que existem comandos que precisam ser executados como usuários diferentes (além de apenas root e um usuário normal, pode haver um usuário 'build', etc., etc.)

Pergunta: Por favor, ajude-me a entender os prós e contras destes (e quaisquer outras soluções propostas ou melhores). Além disso, se houver um livro definitivo, links, man pages, etc., que abordem como os scripts interagem com as permissões do sistema subjacente que você pode me indicar, também seria ótimo.

Obrigado a todos!

    

Answer 1

Você já investigou coisas como o capistrano , o boneco , ansible ou chef para suas tarefas?

Você não menciona qual é o escopo do seu trabalho, então não tenho idéia se eles são de alguma utilidade para você.

Eu evitaria "suid" a qualquer custo. Não há nenhum ponto de usá-lo com o sudo instalado, o que parece ser a melhor escolha para suas necessidades de executar comandos com diferentes permissões / IDs de usuário ('sudo -u user2 command2', etc).

Além disso, você pode querer executar alguns comandos sudo sem senha como comandos permitidos em sua sessão ssh baseada em chave (ssh sshkeyaccessonlyuser @ yourhost 'comando sudo'). Isso pode resolver o problema de armazenamento em cache se você não quiser mais caches de senhas no sudo, e seu script não terminará de executar um comando sudo a tempo.

    

Answer 2

Sim, você pode su para qualquer usuário em um script como root sem precisar de uma senha. Isso é um pouco complicado, mas vai funcionar. Você pode ter alguns soluços ao longo do caminho (seu ambiente muda quando você su, por exemplo), mas você será capaz de fazê-lo funcionar. Eu não acho que é "certo". Além disso, o root pode fazer tudo, então você sempre pode encontrar uma maneira de fazer tudo como root.

Eu recomendo usar o sudo para tudo.

Para coisas interativas, o sudo com prompts de senha é OK. Eu prefiro que você peça sua própria senha, não a de root. Desta forma, você pode conceder direitos administrativos limitados, sem dar a senha do root (e, portanto, privilégios totais). Ter que digitar sua senha é bom para o "ei! Estou digitando minha senha, isso significa que estou fazendo algo potencialmente perigoso, vamos verificar antes de digitar". Você também pode configurar o sudo para não solicitar repetidamente senhas (ou seja, uma vez digitadas, as invocações do sudo dentro de n minutos não são solicitadas).

Além disso, você pode fazer com que o sudo deixe um usuário executar qualquer ação como root, não apenas um conjunto limitado de comandos. Eu uso isso em caixas eu admin; é melhor do que "su -", fornece algumas coisas de auditoria prontas, você sempre pode "sudo -i" (ou "-s", às vezes) para obter um shell de root, etc.

Para coisas não interativas, há mais opções.

Eu não gosto muito de binários suid. Isso deve ser usado apenas para binários muito usados que precisam de privilégios de root, que são muito simples e que foram completamente auditados. O ping, por exemplo, requer privilégios de root para fazer seu trabalho. No entanto, qualquer falha de segurança em um binário suid é potencialmente muito perigosa.

Usar o ssh é uma maneira muito complexa de conseguir isso.

Use o sudo, configure-o para não exigir uma senha para os comandos específicos exigidos pelo script. "man sudoers" é uma leitura longa, mas definitivamente interessante - há muitas coisas que você pode fazer com o sudo ...

    

Answer 3

Eu iria com # 4:

Leave in sudo for any scripted commands that require root: system 'sudo rake ts:rebuild'

Você não precisa se preocupar muito com solicitações repetidas de senha; O sudo armazenará em cache o fato de que você autenticou com uma senha por um curto período de tempo (por volta de 5 minutos por padrão. Da página man:

Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in sudoers).

de man sudoers :

timestamp_timeout

Number of minutes that can elapse before sudo will ask for a passwd again. The default is 5. Set this to 0 to always prompt for a password. If set to a value less than 0 the user's timestamp will never expire. This can be used to allow users to create or delete their own timestamps via sudo -v and sudo -k respectively.

Assim, contanto que o script leve < 5 minutos para ser executado, o usuário verá apenas um aviso de senha - nenhum, se tiver autenticado recentemente.

    

Answer 4

Eu também vou sudo, com a solução 1 e 5. Note que você também pode usar aliases para tornar sua configuração mais limpa, como:

Cmnd_Alias RUBY_TOOLS = /path/to/cmnd1, /path/to/cmnd2, etc.
Cmnd_Alias RUBY_TOOLS_NPW = /path/to/cmnd3
User_Alias RUBY_USERS = user1, user2, etc.
User_Alias RUBY_SPECIAL_USERS = root
RUBY_USERS ALL=(RUBY_SPECIAL_USERS) RUBY_TOOLS, NOPASSWD: RUBY_TOOLS_NPW

A regra restringirá o acesso ao (s) comando (s) RUBY_TOOLS como usuário (s) RUBY_SPECIAL_USERS e não usará nenhuma senha para RUBY_TOOLS_NPW.

O Sudo é muito flexível. Você também pode jogar com Host_Alias para especificar hosts nos quais aplicar as regras. Se você precisar automatizar a geração de suas regras de sudo, você pode usar Augeas para isso.

As únicas desvantagens desse método que vejo são:

1. sudo é necessário na máquina (meio óbvio)
2. você precisa chamar o sudo sempre que quiser que um script seja executado

Uma forma de contornar a segunda questão é configurar uma variável SUCMD em sua configuração e usá-la na frente de todas as suas chamadas exec. Por padrão, o SUCMD será sudo, mas você pode configurá-lo para 'su' mais tarde, se desejar usar outro sistema, ou simplesmente para nada se não quiser usar um SUCMD e configurar seu sistema com privilégios setuid ou group.

    

Answer 5

Gostaria de dizer que, em primeiro lugar, não estou familiarizado com o Ruby, pois parece ser uma escolha pouco convencional como uma linguagem para tarefas administrativas. Olhando para as opções listadas abaixo, 5 parece ser a melhor escolha. Se alguma parte do seu script precisar de permissões de root, eu diria que a execução do script requer permissão de root.

Dê todas as opções acima, eu não vi a opção de executar o script como root e apenas executar "su username" antes de executar comandos como o usuário. Ele tem o benefício de não exigir prompts de senha (não precisa de permissões de senha como root) e deve atender a todas as suas necessidades.

Executar script como root fazer um monte de tarefas como root, su newUser fazer um monte de tarefas como newUser, exit (sai de volta para o usuário root) fazer mais algumas tarefas como root.

    

Answer 6

Há outro método aqui que eu usei de tempos em tempos. Se você realmente não quer uma senha, e não quer depender do sudo, você pode usar um script suid wrapper que chama seu script. "sudo" tem suas vantagens, mas às vezes é mais difícil de usar do que um simples wrapper, digamos de um cron job ou como PARTE de outro script.

Eu tive que fazer isso no meu processamento de registro na web. Um script sendo executado como um usuário normal removeria os arquivos de log do caminho, então ele chamava um script suid para enviar um HUP ao apache para reabrir os novos arquivos de log. Apenas o HUP precisava rodar como root, então apenas aquela parte foi suid.