☰

Предоставление групповых разрешений на файлы других пользователей

tag-icon • tag-icon permissions files
Предоставление групповых разрешений на файлы других пользователей

Я использую Debian 7 и создал нового пользователя (веб-сайт) с каталогом htdocs, например:

$ sudo adduser website
$ sudo mkdir -p /home/website/htdocs
$ sudo chown -R website /home/website

Теперь я хочу, чтобы пользователи другой группы (разработчики) имели доступ к каталогу пользователя. Я пробовал:

$ sudo chown -R :developers /home/website

Я вижу, что группа назначена (с помощью ls -laили stat) и что пользователи находятся в группе, но у них нет доступа, верно?

drwxr-xr-x     3     website     developers     4096 May 3 09:09     website

Я также хочу:

  • Разрешить другой группе «подрядчиков» доступ к файлам веб-сайта

  • Ограничить доступ пользователей веб-сайта только к их домашним каталогам

  • Убедитесь, что новые файлы веб-сайта наследуют эти разрешения

Обязательно ли использовать списки контроля доступа или есть лучший способ сделать это (например, не использовать отдельного пользователя для каждого сайта)?

решение1

Трудно давать точные команды, не зная ОС или дистрибутив; и да! ACL подойдет, но есть и стандартный способ.

Есть adduserи useradd, один из них в вашем дистрибутиве может автоматически создать домашний каталог пользователя. Если это так, то содержимое каталога /etc/skel/будет скопировано в домашний каталог пользователя, установлены разрешения и, возможно, могут быть выполнены некоторые другие соответствующие действия.

Могут существовать группы, предварительно определенные для совместного использования, например, «персонал»; но если мы хотим создать собственную группу для совместного использования, в этом нет ничего плохого. Поэтому создайте новую группу или используйте существующую группу. Убедитесь, что пользователи, которые должны быть членами группы, были определены как таковые с помощью usermod, moduser, или vigr, возможно, в соответствии с операционной системой. Каждый пользователь, который в данный момент вошел в систему, должен выйти из системы и войти снова, чтобы стать членом новой группы.

Создайте каталог, общий для всех пользователей, например, /home/share_directory/или любой другой каталог, который имеет наибольший смысл для вашей ситуации. Соответствующая передовая практика — не использовать каталогв пределахдомашний каталог любого пользователя. Если никто, кроме владельца и группы, не должен видеть файлы в каталоге, то измените права доступа к каталогу на 0770. Если чтение разрешено "другим", то используйте 0775. Владелец каталога почти наверняка должен быть root.

chown root:group_name /home/share_directory/

Далее измените бит setuid.

chmod +s /home/share_directory/

Если ни один пользователь не должен иметь возможности изменять файл другого пользователя, то также установите бит stick.

chmod +t /home/share_directory/

В этих примерах одновременно устанавливаются биты setuid и sticky с использованиемвосьмеричная запись.

chmod 5775 /home/share_directory/

или

chmod 5770 /home/share_directory/

Для обновленного вопроса, похоже, ACL — правильный инструмент. Большинство дистрибутивов Linux теперь включают эту aclопцию в defaultsопцию. Если ваш дистрибутив не включает эту aclопцию по умолчанию, то для начала ее использования нужно немного поработать. Сначала смонтируйте файловые системы с опцией aclв /etc/fstab.

sudo vim /etc/fstab
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 defaults,acl 0 1

При необходимости перемонтируйте файловую систему: sudo mount -o remount,acl /. Затем создайте группу, к которой может принадлежать пользователь для этой цели. Возможно, вам также понадобится установить инструменты ACL: apt-get install acl.

sudo groupadd developers
sudo usermod -a -G developers $username

(Или группа может быть "contractors".) Текущий вошедший в систему пользователь должен выйти из системы и войти снова, чтобы стать членом новой группы. Конечно, не делайте этого, если у вас есть содержимое в каталоге /var/www, которое вы хотите сохранить, но просто для иллюстрации его настройки для начала:

sudo rm -rf /var/www
sudo mkdir -p /var/www/public
sudo chown -R root:developers /var/www/public
sudo chmod 0775 /var/www/public
sudo chmod g+s /var/www/public
sudo setfacl -d -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g::rwx,o::r-x /var/www/public
sudo setfacl -d -m u::rwx,g:contractors:rwx,o::r-x /var/www/public
sudo setfacl -m u::rwx,g:contractors:rwx,o::r-x /var/www/public

Выше, разница между setfaclкомандами заключается в следующем: первый экземпляр использует группу по умолчанию (группа-владелец каталога), а второй указывает группу явно. Переключатель -dустанавливает маску по умолчанию ( -m) для всех новых объектов файловой системы в каталоге. Тем не менее, нам также нужно снова запустить команду без переключателя, -dчтобы применить ACL к самому каталогу. Затем замените ссылки на "/var/www" на "/var/www/public" в конфигурационном файле и перезагрузите.

sudo vim /etc/apache2/sites-enabled/000-default
sudo /etc/init.d/apache2 reload

Если мы хотим ограничить удаление и переименование для всех, кроме пользователя, создавшего файл: sudo chmod +t /var/www/publicТаким образом, если мы хотим создать каталоги для фреймворков, которые существуют за пределами корня документов Apache или, возможно, создать каталоги с возможностью записи на сервер, это по-прежнему просто.

Каталог журналов Apache, доступных для записи:

sudo mkdir /var/www/logs
sudo chgrp www-data /var/www/logs
sudo chmod 0770 /var/www/logs

Каталог библиотеки, читаемый Apache:

sudo mkdir /var/www/lib
sudo chgrp www-data /var/www/logs
sudo chmod 0750 /var/www/logs

Небольшая «игра» с каталогом, который не имеет значения, должна помочь сделать это как раз подходящим для вашей ситуации.

Что касается ограничений, я использую два разных подхода: оболочка, rssh, была создана для предоставления доступа SCP/SFTP, но не доступа SSH; или, чтобы ограничить использование домашним каталогом, вы можете использовать внутреннюю подсистему sftp, настроенную в /etc/ssh/sshd_config.

Subsystem sftp internal-sftp

Match group sftponly
  ChrootDirectory /home/%u
  X11Forwarding no
  AllowTcpForwarding no
  ForceCommand internal-sftp

Создайте группу с именем, например, sftponly. Сделайте пользователей членами группы sftponly. Измените их домашние каталоги на /из-за chroot. Каталог /home/username должен принадлежать пользователю root. Вы также можете установить оболочку пользователя на /bin/false, чтобы запретить доступ по SSH. В основном меня беспокоит интерактивный доступ, поэтому обычно следуйте пути rssh. (Они не могут писать никуда, кроме тех мест, где я определил возможность записи.)

Связанный контент