Executando trabalhos iniciados como usuários não privilegiados

Qual é a maneira canônica de ter um trabalho inicial alterar seu ID do usuário e executar o script como um usuário não privilegiado?

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

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

Perguntando no canal #upstart no freenode, a opinião 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...]

Que tal usar o start-stop-daemon?

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

Do livro de receitas Upstart :

O método recomendado para sistemas Debian e Ubuntu é usar o utilitário auxiliar start-stop-daemon. […] start-stop-daemonNão impõe limites de PAM ("Módulo de autenticação conectável") ao processo que ele inicia.

Nota: start-stop-daemonnão suportado no RHEL.

Existem várias maneiras de fazer isso, todas com semânticas ligeiramente diferentes, principalmente relacionadas à participação no grupo:

• setuidgid colocará você no grupo que você especificar.

  • Os daemontools originais colocarão setuidgidvocê apenas nesse grupo, para que você não possa acessar arquivos pertencentes a outros grupos dos quais você é membro.
  • A setuidgidpartir daemontools-bis ea setuidgidpartir do conjunto de ferramentas nosh ambos têm um -s(aka --supplementaryopção), que vai colocá-lo nesse grupo, e também colocá-lo em todos os grupos suplementares para o usuário que você especificar.

• O uso newgrpassim que você se tornar o usuário menos privilegiado adicionará um único grupo ao seu conjunto de grupos, mas também cria um novo subshell, tornando difícil o uso de scripts internos.

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

• chpst -u username:group1:group2:group3... commandnamepermitirá que você especifique exatamente quais membros do grupo adotar, mas (no Ubuntu ) ele só vem com o runitpacote, que é uma alternativa ao upstart.

• su -c commandname usernameseleciona todas as participações em grupos de nomes de usuário sudo -u username commandname, assim como provavelmente é o caminho para menos espanto.

Use setuidgidna embalagem daemontools.

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

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

Também lutei com algumas das outras estrofes novas . Estou chamando um aplicativo python com virtualenvparâmetros específicos e alguns para o meu programa executado.

A seguir, 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 PYTHONPATHobjetivo é obter alguns pacotes instalados da origem no caminho do módulo PYTHON quando esse trabalho inicial for executado. Eu tive que fazer tudo em caminhos absolutos, porque a chdirestrofe 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 acho) não foi rastreado pelo 'expect fork 'ou' expect daemon '.

Acabei de fazer

chown user:group executable
chmod +s executable

(ou seja, defina o bit setuid e altere 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.

Há uma terceira possibilidade, dependendo do que você está tentando realizar. Você poderá soltar os controles de acesso nos arquivos / dispositivos em questão . Isso pode permitir que um usuário não privilegiado monte ou acesse itens aos quais normalmente não teria permissão. Apenas tenha certeza de que não está dando as chaves do reino no processo.

Você também pode alterar o tempo limite do cache da senha sudo . Mas eu não 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 de que há muito poucas maneiras de realizar ações privilegiadas e que realizam escusado será necessário o registo. 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 dos seus arquivos de log for preocupante, provavelmente algo está errado. Sudo gera apenas uma linha por uso em condições normais.

No CentOS 6, versão 0.6.5, o seguinte funcionou para mim.

script

    exec su user_name << EOF
        exec /path/to/command [parameters...]
EOF

end script

ou:

script

    exec su user_name << EOF
       ..... what you want to do ....
EOF

end script

Quando usar

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

o processo do trabalho não pode ser parado initclt stop. Eu acho que o motivo é:

1. the job forked and the main process is not tracked.
2. the main process changed its process group,because of `su -c`