Назад | Перейти на главную страницу

Сохранять бит setgid (после установки bower или сборки gulp)

Мы запускаем веб-серверы, где возникает следующая ситуация:

  1. Пользователь www-data запускает веб-сервер и должен иметь доступ для чтения и записи к файлам.
  2. Пользователь развертывания развертывает весь код
  3. Пользователи bob и alice могут входить в систему через ssh и изменять конфигурации локально.

Все пользователи должны иметь доступ для чтения и записи в / var / www / mysite. В настоящее время мы достигаем этого, владея группой / var / www / site для www-data. Затем мы устанавливаем бит write + setgid для группы, чтобы убедиться, что все подкаталоги имеют одинаковые права.

Некоторое время все работает нормально, но у нас есть проблемы со следующими сценариями:

  1. Мы используем bower для установки пакетов с bower install. Пользователь, который запустил bower install впервые владеет public/bower_components каталог и бит setgid не установлен
  2. Мы используем gulp для минимизации javascripts из public/scripts/src к public/scripts/dist и первый пользователь, который запустил gulp build владеет файлами

В обеих ситуациях find path/to/dir -type d -exec chmod g+ws {} \; смягчает проблему, но можно ли решить эту проблему в первую очередь? Мы установили бит setgid на /var/www/mysite каталог, так почему bower install не следовать этому набору разрешений?

Если нет, есть ли лучший способ решить эту проблему? Мы думали установить биты в процессе автоматизации развертывания, но если пользователь забывает бит setgid, мы думаем, что автоматическое развертывание также может застрять.

ACL Posix - единственный четкий и элегантный способ сделать это, именно так я справляюсь с конфликтами общих ресурсов чтения / записи, особенно в веб-системах. Вот работающий пример.

В моем примере у меня есть каталог с именем /var/www/html/share. Вдобавок у меня есть пользователи alice, bob, deploy и bower

Сначала я создал группу под названием html а затем добавил пользователей в эту группу.

groupadd html
for i in alice bob deploy bower; do usermod -a -G html $user; done

Затем я добавил файл ACL против этого html группу в эту папку.

setfacl -m g:html:rwx /var/www/html/share
setfacl -d -m g:html:rwx /var/www/html/share

Вторая команда важна, она вызывает наследование.

Теперь мы можем проверить его поведение.

# for user in alice bob bower deploy; do \
    sudo -u $user touch "/var/www/html/share/file_${user}" \
done

[root@localhost html]# ls -l /var/www/html/share/
total 0
-rw-rw-r--+ 1 alice  alice  0 May 13 23:08 file_alice
-rw-rw-r--+ 1 bob    bob    0 May 13 23:08 file_bob
-rw-rw-r--+ 1 bower  bower  0 May 13 23:08 file_bower
-rw-rw-r--+ 1 deploy deploy 0 May 13 23:08 file_deploy
[root@localhost html]# 

На первый взгляд кажется, что все права собственности на файлы просты и не позволяют одному пользователю взаимодействовать с другим. Однако мы можем проверить ACL, используя getfacl который показывает больше информации.

# getfacl file_Al
getfacl: file_Al: No such file or directory
[root@localhost share]# getfacl file_alice 
# file: file_alice
# owner: alice
# group: alice
user::rw-
group::r-x          #effective:r--
group:html:rwx          #effective:rw-
mask::rw-
other::r--

Вы можете видеть, что html группа имеет контроль над этими файлами.

Примечание: стандартное разрешение UNIX GROUP обозначает маску разрешений. Как есть rw для файлов это также эффективно rw для ACL, несмотря на то, что фактически предоставленное разрешение rwx.

Давайте проверим, могут ли другие пользователи изменять / удалять эти файлы.

# sudo -u alice /bin/bash
[alice@localhost share]$ pwd
/var/www/html/share
[alice@localhost share]$ echo "hello world" >>file_alice
[alice@localhost share]$ echo "hello world" >>file_bob
[alice@localhost share]$ echo "hello world" >>file_deploy
[alice@localhost share]$ echo "hello world" >>file_bower
[alice@localhost share]$ ll
total 16
-rw-rw-r--+ 1 alice  alice  12 May 13 23:15 file_alice
-rw-rw-r--+ 1 bob    bob    12 May 13 23:15 file_bob
-rw-rw-r--+ 1 bower  bower  12 May 13 23:15 file_bower
-rw-rw-r--+ 1 deploy deploy 12 May 13 23:15 file_deploy
[alice@localhost share]$ rm file_deploy

Наконец, хитрость. Что происходит, когда Алиса создает каталог?

[alice@localhost share]$ mkdir dir_alice;
[alice@localhost share]$ ls -l 
total 12
drwxrwxr-x+ 1 alice alice  0 May 13 23:16 dir_alice
-rw-rw-r--+ 1 alice alice 12 May 13 23:15 file_alice
-rw-rw-r--+ 1 bob   bob   12 May 13 23:15 file_bob
-rw-rw-r--+ 1 bower bower 12 May 13 23:15 file_bower
[alice@localhost share]$ getfacl dir_alice
# file: dir_alice
# owner: alice
# group: alice
user::rwx
group::r-x
group:html:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:html:rwx
default:mask::rwx
default:other::r-x

Потому что мы прошли -d к setfacl он предписывает новым каталогам также наследовать (и применять это наследование к другим подкаталогам). Итак, теперь как пользователь deploy мы можем добавлять и редактировать существующие файлы внутри этого нового подкаталога.

[alice@localhost share]$ touch dir_alice/file_indir_alice
[alice@localhost share]$ exit
exit
# sudo -u deploy /bin/bash
[deploy@localhost share]$ cd /var/www/html/share/dir_alice/
[deploy@localhost dir_alice]$ touch file_indir_deploy
[deploy@localhost dir_alice]$ rm file_indir_alice 
[deploy@localhost dir_alice]$ 

Вы перепутали семантику sticky и setgid.

Бит залипания в каталоге используется, когда нескольким пользователям разрешено создавать файлы и каталоги в этом каталоге, но им разрешено изменять только те, которые они создали сами, им не разрешено вмешиваться в это содержимое, созданное другими пользователями. В /tmp directory - типичный вариант использования для этого.

Липкий бит не наследуется подкаталогами. Нет необходимости наследовать его, чтобы соответствовать своему прямому назначению. Подкаталоги, созданные в прикрепленном каталоге, по умолчанию должны быть запрещены для всех, кроме создателя.

Бит setgid в каталоге указывает, что файлы и каталоги, созданные внутри этого каталога, наследуют группу от каталога, а не получают текущую группу пользователя, создавшего ее. Бит setgid наследуется новыми каталогами, созданными внутри каталога setgid.

Бит setgid может частично достичь цели, которую вы пытаетесь достичь. Это достигнет той части, где вся иерархия каталогов и файлов будет иметь одну и ту же группу (если это явно не переопределено).

Однако это не гарантирует, что группа сможет записать все содержимое. Этого можно добиться с помощью настройки umask.

Umask указывает набор битов, которые не должны устанавливаться для вновь создаваемых файлов и каталогов. Типичные значения umask: 0002, 0007, 0022, 0027, 0077. В вашем случае вы хотите, чтобы эти каталоги были доступны для записи для группы, что означает, что вы хотите либо 0002 что означает, что созданное будет доступно для чтения всем вне группы или 0007 Это означает, что то, что создано, недоступно для всех за пределами группы.

Перед созданием новых файлов или каталогов необходимо убедиться, что в какой-то момент установлена ​​маска umask. Umask наследуется дочерними процессами. Остерегайтесь файлов, созданных за пределами этого конкретного каталога, поскольку маска umask применяется и в другом месте, поэтому все, что создано в другом месте, по-прежнему будет доступно для записи группой, даже если это другая группа, чем та, которая используется в /var/www иерархия.

Вы можете попытаться усложнить сброс разрешений корневого каталога, добавив его только с помощью болтать:

chattr +a /var/www/mysite