Nginx:proxy_store_access 옵션이 작동하지 않는 것 같습니다

Nginx:proxy_store_access 옵션이 작동하지 않는 것 같습니다

Rails 앱용 nginx를 통해 파일 업로드를 처리하기 위해 Proxy_pass를 사용하고 있으며 파일 권한을 제외하고는 잘 작동합니다. 현재 구성 블록은 다음과 같습니다.

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는 내가 정의한 업스트림으로 내 로컬 Rails 서버(127.0.0.1:3000)만 가리킵니다.

파일이 통과하여 tmp 위치에 저장됩니다. 여기에서 request.headers['X-FILE']다음과 같은 내용을 읽었습니다.

문제는 파일이 다른 사용자(nginx가 실행되는 www-data)가 소유하고 있고 읽을 그룹이 없기 때문에 sudo chmodRails 애플리케이션에서 조작하지 않고는 파일을 가져올 수 없다는 것입니다. 그것은 매우 취약하고 신뢰할 수 없는 것으로 밝혀졌습니다.

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

이 페이지를 기반으로 : http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass 이 옵션을 추가했습니다

      proxy_store_access user:rw group:rw all:r;

내 생각에는 으로 설정하는 것이 -rw-rw-r--내 목적에 적합하다고 생각합니다. 그러나 nginx를 다시 시작하고 다시 시도한 후에도 여전히 통과합니다 -rw-------. 즉, 새 옵션이 작동하지 않는 것 같습니다.

누구든지 내가 뭘 잘못하고 있는지, 문제를 어떻게 진단할 수 있는지 알 수 있나요? Nginx 버전 1.9.7을 사용하고 있습니다.

실제로 ngx_http_proxy_module이 설치되어 있는지 100% 확신할 수 없습니다. 그렇지 않으면 Proxy_pass 항목이 완전히 실패할 것이라고 생각하지만 아마도 그렇지 않을 수도 있습니다. 이 모듈이 있는지 테스트하는 방법은 무엇입니까?

고마워요, 맥스

편집: 또한 다른 폴더를 사용하여 임시 파일을 작성하려고 할 때 ngnix도 폴더의 소유권을 갖는다는 것을 확인했습니다. 즉, 파일 업로드를 수행하기 전에 폴더는 의 소유 max:max입니다 www-data:max. 관련 있는.

답변1

이를 수행하는 유일한 방법은 src/os/unix/ngx_files.c(또는 필요한 권한)에서 파일 생성 마스크를 편집하고 변경한 후 nginx를 다시 컴파일하는 것입니다.ngx_open_tempfile06000660

이 값 때문에 nginx init 스크립트에서 umask를 변경하는 것은 도움이 되지 않습니다 0600.

프록시 모듈과 같은 사용 가능한 구성 설정 user:이 없습니다 .group:other:client_body_temp_path

이 함수 ngx_open_tempfile가 읽은 변수조차도 access다음 모듈과 같이 호출하는 것 이외의 다른 것으로 설정될 수 있습니다 0600.ngx_conf_set_access_slot

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,

nginx 코어의 일부인 클라이언트 코드에서는 작동하지 않습니다. 따라서 다시 컴파일해야 합니다.

애플리케이션이 속한 그룹의 디렉터리를 업데이트하는 것 외에도 nginx가 쓰는 파일이 해당 그룹의 소유가 0600되도록 해당 디렉터리에 gid()를 설정해야 합니다.0660chgrp your_app_server_groupclient_body_temp_pathchmod g+s your_app_server_group

답변2

내 프로젝트에서 비슷한 문제에 직면했습니다. 내 목표는 Nginx가 업로드를 처리한 다음 이를 Django 애플리케이션에 전달하도록 하는 것입니다. Django 애플리케이션에 문제가 있더라도 업로드가 성공하여 디스크에 저장되기를 바랍니다.

@jaygooby의 말이 맞습니다. 소스 코드를 변경하지 않고는 Nginx에게 다른 사용자, 그룹 또는 권한으로 파일을 쓰도록 지시할 수 없습니다.

하지만 당신은 사용할 수 있습니다파일 시스템 바인딩이 폴더를 가리키는 추가 마운트 지점을 만듭니다 client_body_temp_path.

BindFS 설치
Ubuntu에서: apt-get install bindfs
다른 운영 체제를 사용하는 경우 다음을 확인하세요.파일 시스템 바인딩웹사이트.

폴더 생성
폴더가 있는지 확인하세요. 적절한 소유권과 권한을 할당합니다.

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

client_body_temp_path나는 폴더를 가리켰다 incoming. 폴더 processing는 자동화된 미러 역할을 하여 적절한 소유권과 권한이 있는 파일에 대한 액세스를 제공합니다.

마운트 지점 구성
/etc/fstab재부팅 후 폴더가 자동으로 마운트되도록 다음 줄을 추가하십시오 . sudo mount -a을 빠르게 다시 로드할 수 있습니다 fstab.

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

이 명령은 processing폴더를 폴더에 마운트 하고 incoming, 소유자/그룹을 재정의하고, 읽기+쓰기 권한을 할당하도록 지시합니다.

애플리케이션의 파일 처리
$request_body_file제목에서 추출됩니다(예: X-FILE질문에 표시된 대로). 그런 다음 /var/local/incomingparh를 다시 작성하면 /var/local/processing문제 없이 파일을 사용할 수 있습니다.

관련 정보