Questão Executando trabalhos iniciantes como usuários sem privilégios


Qual é a maneira canônica de ter um trabalho inicial mudar seu userid e executar o script como um usuário sem privilégios?

Obviamente, pode-se usar su ou sudo, mas isso parece hacky (e pode gerar linhas de log desnecessárias).


138


origem




Respostas:


Com o upstart v1.4, setuid e setgid são suportados nativamente no arquivo de configuração.


108



Veja o livro de receitas para detalhes sobre isso: upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user - Jason Navarrete
Em outras palavras, é suportado no Precise (12.04) e mais recente. - Edward Anderson
Em outras palavras, não é suportado no centos 6 - socketpair
Para o registro, initctl --version para encontrar sua versão atual do upstart. - Mahn
De maneira irritante, a distribuição do Amazon Linux na AWS usa a versão inicial do RHEL 6 (0.6.5 !!!!) para que qualquer um que use isso tenha que usar a solução 'su'. - Asfand Qazi


Perguntando sobre o canal #upstart na freenode, a abordagem oficial sobre o assunto é:

Uma versão futura do Upstart terá   suporte nativo para isso, mas por enquanto,   você pode usar algo como:

exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]

84



Esta é a única resposta que funcionou no Amazon Linue EC2 (tentei todas as variações de sudo e su, incluindo --session-command, -c, ad nauseum); nenhum deles permitiu que o processo fosse interrompido uma vez iniciado; muito obrigado por isso. - Kato
Essa é uma mágica mágica, +1. - Steve Kehlet
Isso não funcionou para mim no CentOS 6 (Upstart 0.6.5). Há uma série de garfos (4 profunda eu acho) iniciados por su isso significa que expect fork e até mesmo expect daemon Não pegue o PID final. - Mark Lakata
Eu usei isso no Amazon Linux (Upstart 0.6.5) para inicializar um processo Jenkins (que não se daemoniza, felizmente) e funcionou! Eu tive que mudar um pouco para redirecionar a saída padrão para um arquivo de log e definir algumas variáveis ​​de ambiente, mas funcionou! Minha versão parece: exec su -s /bin/sh -c 'HOME=/foo/bar exec "$0" "$@" &>/var/log/foobar.log' username -- /path/to/command [parameters...] - Asfand Qazi


Que tal usar o start-stop-daemon?

exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd

A partir de Livro de receitas upstart:

O método recomendado para os sistemas Debian e Ubuntu é usar o utilitário auxiliar start-stop-daemon. […] start-stop-daemon não impõe limites PAM ("Pluggable Authentication Module") ao processo iniciado.

Nota: start-stop-daemon não suportado no RHEL.


17



Você também pode usar o grupo, se precisar. Com --chuid daemonuser: daemongroup - Evgeny


Há várias maneiras de fazer isso, todas com semânticas ligeiramente diferentes, particularmente relacionadas à associação ao grupo:

  • setuidgid irá colocá-lo no grupo que você especificar.

    • Os daemontools originais setuidgid vai colocar você  nesse grupo, para que você não possa acessar arquivos pertencentes a outros grupos dos quais você é membro.
    • o setuidgid de daemontools-encore e a setuidgid do conjunto de ferramentas ambos têm um -s (a.k.a. --supplementary) opção que irá colocá-lo nesse grupo, e também colocá-lo em todos os grupos suplementares para o usuário que você especificar.
  • Usando newgrp uma vez que você se torna o usuário menos privilegiado irá adicionar um único grupo ao seu groupset, mas também cria um novo subshell, tornando complicado o uso dentro de scripts.

  • start-stop-daemon preserva sua participação no grupo e faz muito mais do que apenas setuid / setgid.

  • chpst -u username:group1:group2:group3... commandname permitirá que você especifique exatamente quais membros do grupo adotar, mas (em Ubuntu) só vem com o runit pacote, que é uma alternativa para upstart.

  • su -c commandname username pega todos os membros do grupo do nome de usuário, assim como sudo -u username commandname, então eles são provavelmente o caminho para menos espanto.


13





Usar setuidgid da embalagem daemontools.

Documentação aqui: http://cr.yp.to/daemontools/setuidgid.html


8



daemontools não é um pré-requisito para o upstart, então isso não parece ser a resposta 'canônica' - Adam Nelson
Além disso, o daemontools está no universo (Ubuntu 10.04), e o upstart está no main. - jtimberman


Em uma instância do Ubuntu 10.10 no Amazon EC2, tive melhor sorte com o start-stop-daemon comando.

Eu também lutei com alguns dos outros novatos estrofes. Eu estou chamando um aplicativo python com um específico virtualenv e alguns parâmetros para o meu programa executado.

O seguinte é o que funcionou para mim.

script
  export PYTHONPATH=.:/home/ubuntu/.local/lib/python2.7/site-packages/:/home/ubuntu/python/lib/python2.7/site-packages/
  exec start-stop-daemon --start  --chuid ubuntu --exec /home/ubuntu/python_envs/MyProj/bin/python /home/ubuntu/www/MyProj/MyProj.py -- --config-file-dir=/home/ubuntu/www/MyProj/config/ >> /home/ubuntu/startup.log 2>&1 &
end script

o PYTHONPATH é obter alguns pacotes instalados da fonte para o PYTHON caminho do módulo quando este job upstart é executado. Eu tive que fazer tudo em caminhos absolutos porque o chdir A estrofe não parecia funcionar.


4



Eu também tive problemas com env variáveis ​​usadas com exec start-stop-daemon. - Thomas Bratt


Eu estava usando o CentOS 6, e não consegui que o hack recomendado (para o Upstart 0.6.5) funcionasse para mim, nem o truque 'su' porque o número de garfos envolvidos (4 eu acho) não foi rastreado pelo 'wait fork' 'ou' esperar daemon '.

Eu acabei de fazer

chown user:group executable
chmod +s executable

(isto é, defina o bit setuid e mude a propriedade).

Pode não ser o método mais seguro, mas para um projeto interno de P & D, não importava no nosso caso.


3



Se você fosse fazer um chmod 1700 ou pelo menos um chmod u+sx,go-x lá em vez de apenas +s, qualificaria como "seguro o suficiente". :) - dannysauer


Existe uma terceira possibilidade, dependendo do que você está tentando realizar. Você pode ser capaz de Solte os controles de acesso nos arquivos / dispositivos em questão. Isso pode permitir que um usuário sem privilégios monte ou acesse itens aos quais normalmente não seria permitido. Apenas tenha certeza que você não está dando as chaves para o reino no processo.

Você também pode alterar o tempo limite do cache de senha sudo. Mas eu não recomendo a menos que sua máquina esteja fisicamente segura (ou seja, você acredita que é improvável que um transeunte tente obter acesso ao sudo).

Há uma boa razão para que haja poucas maneiras de realizar ações privilegiadas e que elas executem desnecessário  necessário exploração madeireira. Restrições frouxas seriam um risco à segurança do seu sistema, e a falta de registro significaria que não há como saber o que aconteceu quando você foi comprometido.

Se o Tamanho de seus arquivos de log é uma preocupação, então provavelmente há algo errado. Sudo gera apenas uma linha por uso em condições normais.


0