Nginx: opção proxy_store_access não parece funcionar

Question

Estou usando proxy_pass para lidar com o upload de arquivos via nginx para um aplicativo Rails, e está funcionando bem, exceto pelas permissões de arquivo. Aqui está o bloco de configuração atual:

location ~ ^my_filename_regex$ {

  limit_except POST { deny all; }
  client_body_temp_path      /path/to/app/tmp;
  client_body_in_file_only   on;
  client_body_buffer_size    128K;
  client_max_body_size       1000M;

  # try_files $uri @slow-rails;
  proxy_pass                 http://elrs;
  proxy_pass_request_headers on;
  proxy_set_header           X-FILE $request_body_file; 
  proxy_set_body             off;
  proxy_redirect             off;

  # might not need?
  proxy_read_timeout         3m;
} 

elrs é um upstream que eu defini para apenas apontar para o meu servidor de rails local (127.0.0.1:3000).

O arquivo chega e é salvo em um local tmp, que eu li em request.headers['X-FILE'] : até agora, tudo bem.

O problema é que o arquivo é de propriedade de um usuário diferente (www-data, que é o que o nginx executa), e não tem leitura de grupo, então não consigo fazer isso sem sudo chmod no meu aplicativo rails, que está se mostrando bastante frágil e não confiável.

-rw------- 1 www-data www-data 1430753 Feb 23 13:36 /path/to/app/tmp/0057375433

Com base nesta página: link Eu adicionei esta opção

      proxy_store_access user:rw group:rw all:r;

que eu pensei que iria configurá-lo para -rw-rw-r-- , o que é bom para os meus propósitos. No entanto, depois de reiniciar o nginx e tentar novamente, ele ainda está aparecendo com -rw------- . A nova opção parece não funcionar, em outras palavras.

Alguém pode ver o que estou fazendo de errado ou como posso diagnosticar o problema? Estou usando o Nginx v 1.9.7.

Eu não tenho 100% de certeza de que eu tenho o ngx_http_proxy_module instalado: eu supus que se eu não fizesse isso o material proxy_pass iria falhar completamente, mas talvez não seja esse o caso. Como posso testar se tem este módulo?

obrigado, Max

EDIT: Eu também notei, enquanto experimentava usar uma pasta diferente para gravar o arquivo temporário, esse ngnix também estava assumindo a propriedade dessa pasta: ie, antes de fazer o upload do arquivo, a pasta pertencia a max:max e agora é de propriedade de www-data:max . Acabei de mencionar isso, caso seja relevante.

    

Answer 1

A única maneira de fazer isso é recompilar o nginx :( após editar src/os/unix/ngx_files.c e alterar a máscara de criação de arquivos em ngx_open_tempfile de 0600 para 0660 (ou qualquer perms que você precisar).

Alterar o umask no script init do nginx não ajuda por causa desse valor 0600 .

Não há nenhuma configuração de configuração user: , group: ou other: disponível para client_body_temp_path , como há para o módulo proxy.

Mesmo que a função ngx_open_tempfile leia a variável access que poderia ser definida como algo diferente de 0600 chamando ngx_conf_set_access_slot como é para esses módulos:

src/http/modules/ngx_http_uwsgi_module.c
171:      ngx_conf_set_access_slot,

src/http/modules/ngx_http_dav_module.c
102:      ngx_conf_set_access_slot,

src/http/modules/ngx_http_scgi_module.c
111:      ngx_conf_set_access_slot,

src/http/modules/ngx_http_fastcgi_module.c
254:      ngx_conf_set_access_slot,

src/http/modules/ngx_http_proxy_module.c
291:      ngx_conf_set_access_slot,

não está disponível para o código do cliente que faz parte do núcleo do nginx. Daí a necessidade de recompilar.

Além de atualizar o 0600 para 0660 , você precisará do diretório chgrp your_app_server_group the client_body_temp_path para o grupo ao qual o seu aplicativo pertence e, em seguida, definir também nele ( chmod g+s your_app_server_group ). arquivos escritos nele pelo nginx são de propriedade daquele grupo.

    

Answer 2

No meu projeto, eu estava tendo um problema semelhante. Meu objetivo era deixar o Nginx lidar com o upload e depois passá-lo para um aplicativo do Django. Mesmo que algo desse errado no aplicativo Django, eu ainda queria que o upload fosse bem-sucedido e fosse armazenado no disco.

@jaygooby está certo, você não pode instruir o Nginx a escrever o arquivo sob um usuário, grupo ou permissões diferentes sem alterar o código-fonte.

No entanto, você pode usar bindfs para criar um ponto de montagem extra que aponte para a pasta client_body_temp_path .

Instalar o BindFS
Sob o Ubuntu: apt-get install bindfs
Se você estiver usando um sistema operacional diferente, dê uma olhada no site bindfs .

Crie as pastas
Certifique-se de que as pastas existam. Atribuir a propriedade e permissões adequadas.

mkdir /var/local/incoming
mkdir /var/local/processing

Eu aponto client_body_temp_path para a pasta incoming . A pasta processing atuará como um espelho automático que fornecerá acesso aos arquivos com a propriedade e as permissões adequadas.

Configure seu ponto de montagem
Adicione a seguinte linha ao seu /etc/fstab , para que ele monte automaticamente a pasta após a reinicialização. Você pode fazer um rápido sudo mount -a para recarregar seu fstab .

/var/local/incoming /var/local/processing
fuse.bindfs force-user=myUser,force-group=myGroup,perms=ug+rw 0 0

O comando instrui para montar a pasta processing na pasta incoming , sobrescrevendo o proprietário / grupo e atribuindo permissões de leitura + gravação.

Manipule o arquivo em seu aplicativo
Extraia o $request_body_file de um cabeçalho (por exemplo, X-FILE , conforme ilustrado na pergunta). Em seguida, reescreva o /var/local/incoming parh para /var/local/processing e você poderá trabalhar com os arquivos sem problemas.