Com o upstart v1.4, o setuid e o setgid são suportados nativamente no arquivo de configuração.
Qual é a maneira canônica de um trabalho inicial mudar seu ID de usuário 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).
Perguntando sobre o canal #upstart na freenode, o assunto oficial é:
A future release of Upstart will have native support for that, but for now, you can use something like:
exec su -s /bin/sh -c 'exec "$0" "$@"' username -- /path/to/command [parameters...]
Que tal usar start-stop-daemon?
exec start-stop-daemon --start --chuid daemonuser --exec /bin/server_cmd
De Livro de receitas do Upstart :
The recommended method for Debian and Ubuntu systems is to use the helper utility
start-stop-daemon. […]start-stop-daemondoes not impose PAM ("Pluggable Authentication Module") limits to the process it starts.
Nota: start-stop-daemon não é suportado no RHEL.
Existem várias maneiras de fazer isso, todas com semântica um pouco diferente, particularmente relacionadas à associação ao grupo:
setuidgid colocará você no grupo que você especificar.
setuidgid colocará você somente nesse grupo, para que você não possa acessar arquivos pertencentes a outros grupos dos quais você é membro. setuidgid do daemontools-encore e o setuidgid do conjunto de ferramentas ambos têm uma opção -s (aka --supplementary ) que o colocará nesse grupo, e também coloque você em todos os grupos suplementares para o usuário que você especificar. Usar newgrp depois de se tornar o usuário com menos privilégios adicionará um único grupo ao seu groupset, mas também criará um novo subshell, dificultando 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 (no Ubuntu ) ele só vem com o pacote runit , que é uma alternativa para upstart .
su -c commandname username seleciona todos os membros do grupo de nome de usuário, assim como sudo -u username commandname , então eles provavelmente são o caminho para o menor espanto.
Use setuidgid do pacote daemontools .
Documentação aqui: link
Em uma instância do Ubuntu 10.10 no Amazon EC2, tive mais sorte com o comando start-stop-daemon .
Eu também lutei com algumas das outras sub-inscrições . Eu estou chamando um aplicativo python com um virtualenv específico 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 origem para o caminho do módulo PYTHON quando esse trabalho de inicialização é executado. Eu tive que fazer tudo em caminhos absolutos porque a estrofe chdir não parecia funcionar.
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 por 'esperar garfo' ou 'esperar daemon'.
Eu acabei de fazer
chown user:group executable
chmod +s executable
(ou seja, 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 em nosso caso.
Existe uma terceira possibilidade, dependendo do que você está tentando realizar. Você pode ser capaz de afrouxar 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 de 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 seja 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 o logging desnecessário necessário . 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 algo provavelmente está errado. O Sudo gera apenas uma linha por uso em condições normais.