Operação não permitida ao iniciar o Unicorn

Question

Eu criei uma configuração nginx / unicorn / capistrato no Ubuntu (Amazon EC2) seguindo principalmente este guia . Eu acho que tudo está configurado como deveria, mas quando eu começo o Unicorn eu recebo (MUITO) este erro no log:

E, [2012-09-08T08:57:20.658092 #12356] ERROR -- : Operation not permitted (Errno::EPERM)
/home/deployer/apps/bridgekalenderen.no/shared/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/worker.rb:82:in 'initgroups'

Eu vejo que está relacionado às permissões do usuário, mas não consigo entender o que deixei de fora. O servidor inicializa muito bem se eu iniciá-lo com o sudo (ou, rvmsudo, na verdade).

O usuário tem recursos sudo, eu chmod'ed o aplicativo várias vezes para que as permissões de arquivo deve ser ok. O socket de unicórnio em / tmp pertence ao usuário do deployer, então esse não deveria ser o problema.

Alguém sabe onde procurar?

ATUALIZAÇÃO:

Depois de algumas escavações, descobri que isso se resume a uma chamada para Process.initgroups , que gera o EPERM. Eu verifiquei isso no irb. Eu não consigo descobrir o que causa o erro. O usuário pode ler /etc/group .

    

Answer 1

Eu finalmente percebi isso. O problema era que o grupo primário do usuário do implantador estava errado. Deve ser 'staff', mas foi 'deployer'. Isso significa que o unicórnio tenta entregar a propriedade de novos processos de trabalho ao grupo que deveria usar, mas somente o root pode fazer isso.

Apenas para o caso de alguém precisar saber, eu alterei o grupo primário editando /etc/passwd da seguinte forma:

deployer:x:1002:50:,,,:/home/deployer:/bin/bash

'50 'é o gid de' staff '. Era 1002 para começar. Para obter o gid do grupo 'staff', faça:

cat /etc/group | grep staff

Ele vai dizer algo ao longo das linhas:

staff:x:50:<comma separated list of users in this group>

O gid é o número depois de 'x'.

    

Answer 2

Se eu entendi bem, você está tentando iniciar um serviço sem sudo no usuário normal. Isso não funcionará e dará seus erros como os que você recebeu Operação não permitida . Isso é verdadeiro na maioria dos casos (se não todos) porque qualquer serviço exigirá um ou mais dos seguintes procedimentos para realizar seu trabalho:

1. Ligação / escuta nas portas < 1024.
2. Lendo arquivo (s) não legível por non-root.
3. Escrever arquivo (s) não gravável por não raiz.
4. e possivelmente mais (não me lembro).

Answer 3

Encontrei o mesmo problema. O que acabou funcionando para mim foi definir o seguinte na minha configuração de unicórnio no bloco after_fork do |server, worker| : (é da configuração unicorn do github)

  begin
    uid, gid = Process.euid, Process.egid
    user, group = 'deployer', 'staff'
    target_uid = Etc.getpwnam(user).uid
    target_gid = Etc.getgrnam(group).gid
    worker.tmp.chown(target_uid, target_gid)
    if uid != target_uid || gid != target_gid
      Process.initgroups(user, target_gid)
      Process::GID.change_privilege(target_gid)
      Process::UID.change_privilege(target_uid)
    end
  rescue => e
    if RAILS_ENV == 'development'
      STDERR.puts "couldn't change user, oh well"
    else
      raise e
    end
  end

    

Answer 4

Eu perdi um dia de homem recentemente para isso. O contexto estava tentando executar o Unicorn em um usuário chamado apps e o erro Errno :: EPERM continuava nos mordendo. Aqui está o rastreamento de pilha:

E, [2018-04-12T20:45:07.277588 #2048] ERROR -- : Operation not permitted (Errno::EPERM)
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/worker.rb:143:in 'initgroups'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/worker.rb:143:in 'user'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:657:in 'init_worker_process'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:682:in 'worker_loop'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:549:in 'spawn_missing_workers'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:563:in 'maintain_worker_count'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/lib/unicorn/http_server.rb:293:in 'join'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/gems/unicorn-5.4.0/bin/unicorn:126:in '<top (required)>'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/bin/unicorn:23:in 'load'
/apps/cas-seas3/shared/bundle/ruby/2.2.0/bin/unicorn:23:in '<top (required)>'

Instrumentar a base de código com uma instrução print ao redor da linha 143 nos forneceu as seguintes informações de depuração:

user = apps
group=apps
uid=1040
gid=110
whoami=apps
Process.egid = 1001

Essa discrepância entre o gid e o Process.egid causou esse bloqueio de código:

if gid && Process.egid != gid
  Process.initgroups(user, gid)
  Process::GID.change_privilege(gid)
end

e foi isso que causou a falha.

Eu finalmente tracei uma diferença entre o GID / EGID e o problema era que o usuário dos apps pertencia a um grupo primário diferente (admin). Quando mudei o usuário dos aplicativos para o grupo de aplicativos como primário, então funcionou. Isso foi feito editando o arquivo / etc / passwd que definiu as contas de usuário da caixa.

Outra maneira de testar isso é usar o sg para executar manualmente o unicórnio com o grupo correto usando o comando sg assim:

bundle exec sg apps -c unicorn -c /apps/cas-seas3/current/config/unicorn.rb -E deployment -D

Se você achar que funciona, então é um bom sinal para ver suas configurações de usuário / grupo.

Unicorn parece ser muito sensível às configurações de usuário / grupo para verificar / etc / passwd e / etc / group e também usar essa linha ps para verificar a diferença no processo Unicorn de execução para diferenças no UID e GID:

ps -eo uid,gid,egid,args | grep unicorn

Nota: O unicórnio após o gancho acima não funcionou para mim. Nada funcionou, exceto por isso.