Meu problema acabou sendo o próprio rack.
Acontece (como explicado aqui ) que o rack, quando executado com o comando rackup -D (como um daemon), altera o diretório de trabalho para / .
Eu tenho um servidor de temporariedade do Ubuntu na AWS que executa um minúsculo aplicativo Sinatra usando o Thin webserver.
O aplicativo sinatra executa alguns comandos git clone quando invocado e tudo funciona muito bem quando executo rackup do meu usuário.
Naturalmente eu quero rodar o servidor como um daemon, por isso usei rackup -D e invoquei o aplicativo. Desta vez, recebi uma exceção do git que informa ao daemon que não está autorizado a gravar na pasta de destino:
could not create work tree dir 'path/to/clone': Permission denied
Pelo que entendi, os daemons têm os mesmos privilégios que o usuário que os executa, então como a tarefa falha?
Eu também tentei chmod -R 777 o diretório mas não funcionou ..
Meu problema acabou sendo o próprio rack.
Acontece (como explicado aqui ) que o rack, quando executado com o comando rackup -D (como um daemon), altera o diretório de trabalho para / .
Verifique se o executável tem o bit setuid definido. Isso faria com que fosse executado como o proprietário do arquivo, não o usuário que o lançou. Você pode verificar executando ls -l appname e observando o quarto caractere na máscara de permissões (no lugar do bit executável do proprietário). Se for um s , o bit setuid está definido.
Os daemons geralmente são definidos para serem executados com o setuid, portanto, espera-se que eles não tenham as permissões do usuário que os iniciou. Isso está em contraste com aplicativos não daemon, que são esperados para ter as permissões do usuário. Você precisará adicionar o uso do daemon r ao grupo de arquivos que você deseja que sejam afetados e garantir que as permissões do grupo permitam as ações.