Выскочка "единорога" с умаском игнорируется - PullRequest
0 голосов
/ 13 января 2012

Я использую upstart v1.4 для запуска сервера приложений, он называется unicorn.

Файл конфигурации upstart выглядит следующим образом:

description "Unicorn Application Server"

start on network
stop on runlevel [!2345]

umask 0003
setuid unicorn
setgid myproject
chdir /opt/myproject/

respawn

exec /opt/myproject/bin/unicorn --config-file /opt/myproject/config/unicorn.rb --env production

Важно, чтобы процесс выполнялся с 0774, то есть ug+rwxo+r, по крайней мере для каталогов. Пользователь и группа являются общими для таких пользователей, как сервер nginx, загрузки, вход сотрудников и т. Д.

Я заметил, что каталоги созданы с неправильными разрешениями:

drw-rw-r-- 2 unicorn       myproject        4096 2012-01-13 06:58 20120113-0658-7704-4676

Насколько я знаю, ничто в моем приложении не вызывает этого.

В соответствии с подключением gdb к процессу и вызовом call umask(0), эффективный umask равен 75 или 0o113.

Вот сеанс gdb:

root@1:/opt/myproject# cat ./tmp/pids/unicorn.pid 
7600

root@1:/opt/myproject# gdb
GNU gdb (GDB) 7.1-ubuntu

(gdb) attach 7600
Attaching to process 7600

(gdb) call umask(0)
$1 = 75

(gdb) call umask(75)
$2 = 0

(gdb) q
Quit anyway? (y or n) y
Detaching from program: /usr/local/bin/ruby, process 7600

root@1:/opt/myproject# ruby -e 'printf("%o\n", 75)'
113

Маска 113 будет учитывать права доступа к 664, что, по-видимому, и есть то, что я вижу.

Что я здесь не так делаю, Юникорн плохо себя ведет? Выскочка игнорирует мою строфу? Должен ли я определить строфу как 003, а не 0003? Мой сеанс gdb работает и синтаксис %o printf() правильный?

Ответы [ 2 ]

1 голос
/ 16 января 2012

Как "единорог" ведет себя вне среды Upstart?Я бы догадался точно так же, но, пожалуйста, проверьте это (сделайте все максимально простым).

Помните, что значение umask не является абсолютным: как следует из названия, это маска - она ​​«вычитает» разрешениебиты из битов разрешений, которые ваше приложение указывает при открытии файла или создании каталога .Upstarts umask stanza ведет себя исходя из того, что я вижу, поэтому ваша проблема должна быть в том, что приложение unicorn задает для вас нечетный набор битов прав (режим), когда он открывает файлы для записи и создает каталоги.

Попробуйтевзявшись за единорога, чтобы увидеть, что он на самом деле делает:

  strace -o /tmp/strace.log -fFv -s 1024 /opt/myproject/bin/unicorn --config-file ...

Дождавшись, пока единорог создаст несколько файлов и / или каталогов, остановите / убейте его и посмотрите файл /tmp/strace.log. grep для "open (FILE)msgstr "где ФАЙЛ - это имя одного из файлов, которые он создает, например, и посмотрите, что является 3-м аргументом для открытого системного вызова.Когда у вас есть это значение режима, должно быть возможно создать значение umask, чтобы дать файлу необходимые вам разрешения.Обратите внимание, что это предполагает, что единорог:

  • соответствует режиму, который он определяет.
  • не вызывает сам umask (2) (который переопределяетUpstart umask stanza).
  • не вызывает chmod (2) / fchmod (2).

Если - после выполнения вышеописанного процесса - вы все еще думаете, что естьпроблема с Upstart, пожалуйста, предоставьте простой тестовый пример (который не требует единорога) и поднимите ошибку здесь: https://bugs.launchpad.net/upstart/+filebug.

1 голос
/ 13 января 2012

Если вы вместо вызова единорога из раздела exec вызываете скрипт, который просто вызывает "umask >> / tmp / somefile", что он там помещает?Если это дает ожидаемый ответ, ваша проблема в единороге.

...