Linux - client_body_in_file_only - как установить права доступа к временному файлу? - PullRequest
Новая
       8

Linux - client_body_in_file_only - как установить права доступа к временному файлу?

0 голосов
/ 15 февраля 2019

Мы используем опцию client_body_in_file_only с nginx, чтобы разрешить загрузку файлов через Ajax.Конфигурация выглядит следующим образом: 

location ~ ^(\/path1|\path2)$ {

  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;

  #this option is a quick hack to make sure files get saved on (ie this type of request goes to) on a specific server
  proxy_pass                 http://admin;
  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;
}

Это работает, но процесс веб-сервера (Mongrel), который обрабатывает запрос, должен sudo временный файл, поступающий в headers['X-FILE'], прежде чем он сможет сделатьничего с этим.Это связано с тем, что временный файл имеет права доступа 600.

Я не доволен этим подходом, который требует, чтобы мы отредактировали файл /etc/sudoers, чтобы пользователь веб-сервера мог делать sudo chmod без пароля.Это выглядит очень небезопасно.

Есть ли способ, с помощью конфигурации nginx, изменить разрешения для создаваемого временного файла, например, на 775?

РЕДАКТИРОВАТЬ: я только что попытался изменитьзначение параметра umask в конфигурации init nginx, затем перезапуск nginx, но это не помогло.Это было на 0022, я изменил его на 0002.В обоих случаях он имеет 600 разрешений.

EDIT2: я также пытался добавить эту строку под строкой proxy_redirect в конфигурации nginx. 

proxy_store_access user:rw group:rw all:r;

Но это не такне имеет значения - он все еще имеет user:rw

Ответы [ 2 ]

0 голосов
/ 18 февраля 2019

При просмотре источника nginx выясняется, что единственным механизмом, который изменяет разрешения временного файла, является свойство request_body_file_group_access запроса, с которым обращаются в ngx_http_write_request_body():

if (r->request_body_file_group_access) {
    tf->access = 0660;
}

Но даже это ограничивает вас до 0660, и кажется, что это не настраиваемое пользователем свойство, используемое только модулем ngx_http_dav.

Разрешенияв конечном итоге устанавливается в ngx_open_tempfile(), где по умолчанию они равны 0600: 

fd = open((const char *) name, O_CREAT|O_EXCL|O_RDWR, access ? access : 0600);

Таким образом, похоже, что в настоящее время нет решения на основе конфигурации.Если вы хотите / можете собрать nginx из исходного кода, можно применить простой патч для установки разрешений на все, что вы хотите в ngx_http_write_request_body(): 

+    tf->access = 0644;
+
     if (r->request_body_file_group_access) {
         tf->access = 0660;
     }

     rb->temp_file = tf;

Я проверил это и получилследующее, первый файл был загружен без изменения, а второй файл с ним: 

$ ls -al /tmp/upload/
total 984
drwxr-xr-x  2 nobody root     12288 Feb 18 13:42 .
drwxrwxrwt 16 root   root     12288 Feb 18 14:24 ..
-rw-------  1 nobody nogroup 490667 Feb 18 13:40 0000000001
-rw-r--r--  1 nobody nogroup 490667 Feb 18 13:42 0063184684
0 голосов
/ 18 февраля 2019

Кажется, что на данный момент невозможно настроить права доступа к файлу, но существует официальный запрос функции .

Права доступа к файлу всегда 0600, что делаетприложение не может прочитать файл вообще.[...] В настоящее время это неподдерживаемый сценарий: [Nginx] создает временный файл с разрешениями по умолчанию [...] 0600 (если не установлено request_body_file_group_access, но, к сожалению, это свойство не устанавливается).

Билет был открыт в октябре 2018 года с незначительным приоритетом.

...