Permitir que grupo não sudo controle o trabalho inicial


11

Estou tentando configurar um trabalho Upstart para ser executado na inicialização do sistema, e isso também pode ser iniciado / interrompido por membros de um grupo que não seja sudo. Com uma versão anterior, usei update-rc.de os scripts armazenados /etc/init.d/para fazer isso funcionar adicionando %Group ALL = NOPASSWD: /etc/init.d/scriptnameao meu arquivo sudoers, mas não consigo obter um equivalente trabalhando para o Upstart.

Tentei adicionar %Group ALL = NOPASSWD: /sbin/initctl start jobnameao arquivo sudoers, mas tentar executar o comando start jobnameproduz este erro:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

Até onde eu sei, é uma reclamação sobre como minha conta de usuário não tem o poder de enviar mensagens 'Iniciar' no arquivo de configuração do D-Bus para o Upstart. Na verdade, não consegui encontrar nenhuma informação sobre como editar esse arquivo para dar permissão a um grupo para acessar um serviço específico - existe essa opção? Existe uma maneira de editar o arquivo Sudoers para que eu possa executar o trabalho sem editar o arquivo de configuração? Estou melhor apenas aderindo à versão anterior?

Respostas:


7

Você pode começar descobrindo onde a configuração D-Bus específica para Upstart é mantida. Veja esse destination="com.ubuntu.Upstart"trecho da mensagem de erro? Agora tente cumprimentá-lo na pasta com os arquivos de configuração do D-Bus:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />
[...skipped...]

Esse Upstart.confarquivo tem alguns exemplos de políticas. Eu acho que você pode tentar descobrir o formato de uma política a partir deles. Em seguida, tente permitir ao seu usuário específico apenas as ações necessárias. Por exemplo, como em:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"
         send_interface="com.ubuntu.Upstart0_6.Job"
         send_member="Start"/>
</policy>

Isso deve permitir que o pope_benedictusuário inicie esse trabalho.

Observe que os valores para os atributos da diretiva 'allow' estão listados na sua mensagem de erro original.


1
Ah, e não se esqueça de reiniciar o D-Bus depois disso! :)
Iuliu Pascaru

Achei isso um pouco desconcertante, mas isso ajudou: blog.arkency.com/2014/07/…
Mike Campbell

7

Pessoalmente, estou usando a seguinte linha no arquivo /etc/sudoers.d/jobname_myuser:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

conforme descrito aqui: /server//a/390723/68608


2

Essa opção não existe no sudo.

A diferença entre os scripts Sysv e os arquivos de configuração do Upstart é a seguinte: Os scripts Sysv são scripts, executáveis ​​por si só e você pode dizer ao sudo para permitir que algum grupo os execute. Por outro lado, os arquivos de configuração do Upstart são meramente apenas arquivos de configuração, não executáveis; portanto, a execução de start(ligação simbólica para initctl) é o que o sudo permite. Seu problema aqui é que, ao permitir que as pessoas executem, initctlvocê permite que initctltudo funcione .

A solução é simples, se sua preocupação é apenas um trabalho. Faça um script, diga /usr/bin/jobname.shcom

#!/bin/sh
initctl $1 jobname

em seguida, chmod 755 /usr/bin/jobname.she, finalmente, acrescentar que executável para seu arquivo sudoers:

%Group ALL = NOPASSWD: /usr/bin/jobname.sh

Dessa forma, todos podem ligar jobname.sh startou jobname.sh stopcontrolar esse trabalho específico. Você pode querer adicionar um pouco de verificação para permitir que apenas starte stopparâmetros etc.


Em outras palavras, meu problema não é que o sistema negue a capacidade de execução dos membros do grupo initctl, mas que o Upstart recusa quaisquer sinais enviados por usuários / grupos que não tenham recebido explicitamente uma entrada de diretiva Permitir no Upstart.conf? E não há como fornecer mais granularidade do que uma configuração de todos os trabalhos ou nenhum no arquivo de configuração?
Angle O'Saxon

O Initctl, no seu caso, está funcionando bem, mesmo sem a alteração dos sudoers, o Upstart apenas recusa as mensagens, se você não permitir especificamente para usuários não-root. Veja as outras duas respostas. Você pode definir a política do dbus por tarefa (consulte a com.ubuntu.Upstart0_6.<JOB>parte) no Upstart.conf. Dependendo das suas necessidades, pode ser mais simples criar esse tipo de script para ele, em vez de escrever políticas dbus e reiniciar o dbus etc. A política Dbus é obviamente a coisa "certa" a ser feita, mas, dependendo do caso, um script simples pode longo caminho com menos problemas.
Tuminoid

A edição da política DBus para usar com.ubuntu.Upstart0_6.jobnamecomo send_interfacea mesma mensagem de erro gerada anteriormente. Se eu estiver certo ao supor que a saída de erro contém as informações do sinal, parece que a interface ou o destino não refletem o serviço Upstart ao qual o sinal se refere. Acho que as informações de serviço são apenas argumentos na mensagem de chamada do método D-Bus e não tenho certeza se posso editar a política do D-Bus para o Upstart para tomar decisões com base nos valores do argumento.
Angle O'Saxon

Um script do tipo que você sugere está funcionando muito bem para mim, com uma ressalva: estou precisando executá-lo como sudo jobname.sh start, para que o Upstart veja a solicitação como vinda do rootusuário. Estou fazendo um esforço para tentar fazer isso. esse é o caminho "certo" (e, portanto, o afastamento dos scripts do Sys-V em primeiro lugar), então eu gostaria que isso funcionasse através de uma política D-Bus ou alguma outra opção de configuração Upstart, mas se não puder fazer isso funcionar, vou aceitar esta resposta.
Angle O'Saxon

1
Eu também citaria "$1". Com seu [ "$1" = "start" -o "$1" = "stop" ]teste eu acredito que é seguro, mas não indicada $1expansão em uma corrida de script como root é apenas hábito saudável (a menos repartição de palavras é deliberadamente desejado) ...
Beni Cherniavsky-Paskin

0

Como apontado acima, o dbus daemon possui um arquivo de configuração que o especializa para uma aplicação específica.

ls /etc/dbus-1/system.d/
avahi-dbus.conf
bluetooth.conf
...
Upstart.conf
wpa_supplicant.con

O arquivo de configuração também estabelece limites de recursos, parâmetros de segurança e assim por diante.

Para detalhes, consulte dbus-daemon-1 (1) - página de manual do Linux

Para permitir que um grupo inicie / pare tarefas Upstart, adicione a seguinte política ao /etc/dbus-1/system.d/Upstart.conf

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Stop" />
  </policy>

Você deve considerar as implicações de segurança dessa política antes de alterar a política padrão. Os membros do YourGroupName poderão iniciar / parar todos os trabalhos Upstart.


Mas existe uma maneira de limitar os trabalhos que eles podem controlar? Ou isso não é possível porque o D-Bus não presta atenção ao conteúdo da mensagem?
Angle O'Saxon

Tentei adicionar essa política ao Upstart.conf (substituindo o nome do grupo pelo meu nome do grupo atual), reiniciei o D-Bus e obtive start: You do not have permission to modify job: jobnamequando tentei iniciar o serviço.
Angle O'Saxon

ESTÁ BEM. Isso significa que a política é aplicada com sucesso. Parece que o seujob.conf está em / etc / init. Os trabalhos do usuário devem estar em ~ / .init. É plausível no seu caso de uso colocar yourjob.conf em ~ / .init?
Goran Miskovic 11/01

Em relação à sua primeira pergunta: Política define quais interfaces e membros podem ser acessados. Ele define quais conteúdos / argumentos podem ser enviados / transmitidos. A atual política restritiva foi facilitada a montante. Ver não é possível obter arrivista de trabalho do usuário run
Goran Miskovic
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.