Вопрос: Каков наилучший способ обработки разрешений для пользовательских www-данных Apache 2 в / var / www?


Кто-нибудь получил хорошее решение для обработки файлов в /var/www? Мы запускаем виртуальные хосты на основе имени, а пользователь Apache 2 WWW-данные,

У нас есть два обычных пользователя и root. Поэтому, когда возиться с файлами в /var/www, вместо того, чтобы ...

chown -R www-data:www-data

... все время, какой хороший способ справиться с этим?

Дополнительный вопрос: как хардкор вы принимаете разрешения?

Это всегда было проблемой в совместных средах разработки.


210
2018-05-11 05:13


Источник


Также см: Каковы лучшие разрешения linux для моего сайта? - Zoredache


Ответы:


Попытка расширения на @ Zoredache's ответ, поскольку я даю это самому:

  • Создайте новую группу (www-pub) и добавьте пользователей в эту группу

    groupadd www-pub

    usermod -a -G www-pub usera  ## должен использовать -a для добавления к существующим группам

    usermod -a -G www-pub userb

    groups usera  ## группы отображения для пользователя

  • Измените право собственности на все под / var / www на root: www-pub

    chown -R root:www-pub /var/www  ## -R для рекурсивного

  • Изменение разрешений всех папок на 2775

    chmod 2775 /var/www  ## 2 = set group id, 7 = rwx для владельца (root), 7 = rwx для группы (www-pub), 5 = rx для мира (включая пользователя www-data apache)

    Установить идентификатор группы (SETGID) бит (2) приводит к копированию группы (www-pub) ко всем новым файлам / папкам, созданным в этой папке. Другими параметрами являются SETUID (4), чтобы скопировать идентификатор пользователя, и STICKY (1), который, я думаю, позволяет только владельцу удалять файлы.

    Есть -R рекурсивный вариант, но это не будет различать файлы и папки, поэтому вы должны использовать find, вот так:

    find /var/www -type d -exec chmod 2775 {} +

  • Измените все файлы на 0664

    find /var/www -type f -exec chmod 0664 {} +

  • Измените umask для своих пользователей на 0002

    Umask управляет разрешениями на создание файлов по умолчанию, 0002 означает, что файлы будут иметь 664 и каталоги 775. Установка этого (путем редактирования umask линия внизу /etc/profile в моем случае) означает, что файлы, созданные одним пользователем, будут доступны для записи другими пользователями в www-группе без необходимости chmod их.

Проверьте все это, создав файл и каталог и проверив владельца, группу и разрешения с помощью ls -l,

Примечание. Чтобы изменения вступили в силу, вам необходимо выйти из системы / выйти из системы!


201
2017-09-15 05:11



@Tom Замечательно, что вы рекомендуете использовать findдля этого. Один небольшой совет по производительности, который я бы дал, если у вас много файлов / каталогов, и вы используете GNU find для использования + вместо \; так что команда будет работать с несколькими файлами потому как «быстрее запускать команду на максимально возможное количество файлов за раз, а не один раз на каждый файл. Это экономит время, необходимое для запуска команды каждый раз». Кроме того, его легче набирать, поскольку ему не нужна обратная косая черта. - aculich
Обновлено с предложением @ aculich использовать + not \; - Tom
@SunnyJ. попробуйте это (без внешних кавычек): "find / var / www -type f -exec chmod 0664 '{}' \ +" Попробуйте это. Между «{» и «+» есть пробел. - Buttle Butkus
@ Tom-way, чтобы сломать его, спасибо. Просто примечание - я думаю, что «SETUID (4), чтобы скопировать идентификатор пользователя», как указано в вашем ответе, неверен - SETUID игнорируется при применении к каталогам в Linux / Unix - ссылка - Yarin
Хорошо, так usera а также userb ты имеешь ввиду www-data а также ftpuser ? Я нашел это очень запутанным с любым упоминанием www-data, который был в первоначальном вопросе. Кроме того, в чем смысл / преимущество настройки владельца root? Должны ли мы установить ftpuser? - gskema


Я не совсем уверен, как вы хотите настроить разрешения, но это может дать вам отправную точку. Вероятно, есть лучшие способы. Я предполагаю, что вы хотите, чтобы оба пользователя могли изменять что-либо в разделе / ​​var / www /

  • Создайте новую группу (www-pub) и добавьте пользователей в эту группу.
  • Измените право собственности на все под / var / www на root: www-pub.
  • Изменение разрешений всех папок на 2775
  • Измените все файлы на 0664.
  • Измените umask для своих пользователей на 0002

Это означает, что любой новый файл, созданный одним из ваших пользователей, должен быть именем пользователя: www-pub 0664, и любой создаваемый каталог будет именем пользователя: www-pub 2775. Apache получит доступ для чтения ко всему через компонент «другие пользователи». Бит SETGID в каталогах заставит все создаваемые файлы принадлежать группе, которой принадлежит папка. Настройка umask необходима для обеспечения того, чтобы бит записи был настроен так, чтобы любой человек в группе мог редактировать файлы.

Что касается того, насколько хардкором я пользуюсь разрешениями. Это полностью зависит от сайта / сервера. Если есть только 1-2 редактора, и мне просто нужно, чтобы они не слишком сильно нарушали ситуацию, тогда я пойду легко. Если бы бизнес требовал чего-то более сложного, я бы поставил что-то более сложное.


59
2018-05-11 05:49



Возможное дополнение - установите кеширование / загрузку, которые должны быть записаны веб-сервером на www-data: www-data и 775. - gacrux
Будет ли он работать, чтобы добавить пользователей в группу apache вместо того, чтобы полагаться на «другие» разрешения? Если все, что вы делаете, это загрузка файлов, и эти файлы должны быть доступны для чтения апашей, 3-я группа, по-видимому, полезна, если вам нужно отредактировать эти файлы. - Simurr
Есть ли шанс, что вы можете немного расширить это приложение @Zoredache? Я нахожу базовое использование rwx-бит, chmod, chown, adduser, usermod, но вы потеряли меня с дополнительной первой цифрой на восьмеричные разрешения, umasks и все такое. Было бы весьма полезно оценить некоторые примеры команд, иллюстрирующие ваш общий подход. - Tom
Таким образом, каждый пользователь может получить доступ ко всем другим пользовательским файлам! Это означает, что userA может читать config.php userB ... удаляя свои учетные данные mysql, например - drAlberT
Используя acl, вы можете обрабатывать как безопасность, так и совместную работу :) - drAlberT


Я думаю, вы можете найти POSIX ACL (списки управления доступом), чтобы быть полезным. Они допускают более тонкую модель разрешения по сравнению с пользователем: group: other model. Я обнаружил, что их легче держать прямо в голове, так как я могу быть более явным и также могу установить поведение по умолчанию для ветви файловой системы.

Например, вы можете явно указать права каждого пользователя:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Или вы можете сделать это на основе некоторой общей группы:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

И, возможно, вы хотите, чтобы ваш пользователь Apache был доступен только для чтения

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Человеческие страницы:

Руководство


39
2018-05-11 16:26



Это путь ! +1 - drAlberT
ACL для победы +1 ... Подробнее см. serverfault.com/a/360120/41823 - Yarin
Интересно, есть ли недостаток производительности для ACL и базовых разрешений. - Buttle Butkus
К сожалению, ACL слишком часто отсутствует в стандартных установках / дистрибутивах. Мне больно скомпилировать ядро ​​на каждом сервере, которому я управляю, или, что еще хуже, иногда менять файловую систему. Кроме того, при резервном копировании файлов вы должны быть очень осторожны, особенно если вы переключаете серверы. ACL велик, но его текущая поддержка настолько низкая, что я бы рекомендовал против нее для тех, кто не имеет полного контроля над всем, что есть на сервере и в окружении. Но +1 для указания ACL, где это действительно имеет смысл! - Ninj
Хороший ответ +1; Заметка об изменении разрешений чтения / записи процесса apache (www-data например) для чтения только для всего сайта (через setfacl или chmod - или и то, и другое) -> Это, очевидно, блокирует все записи (например, загрузку / обновление плагинов / модулей со стороны браузера на большинстве CMS). Я считаю, что многие популярные также проверяют только доступ на запись на уровне пользователя, а не на уровне группы. Вы все равно можете обновлять, но обновления должны применяться вручную и любые пользовательские разрешения для папок записи (logs / temp / uploads / etc). Только для чтения - отличная защита, если ваш сайт работает с ней. В большинстве случаев этого нет. - bshea


Этот вопрос был снова спросил, и в качестве обсуждается на мета, современные передовые методы обеспечивают более эффективные подходы, чем в 2009 году, когда это было задано. Этот ответ пытается дать некоторые текущие решения для безопасно работать с совместными веб-средами разработки,


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

  • Разделять пользователя на каждом сайте т. е. не обслуживать все сайты, использующие www-data, Это важно, так как в настоящее время Apache редко работает исключительно статический файлы содержимого, но выполняется динамический веб-сайтов. Этот ответ концентрируется на PHP, поскольку это наиболее общий язык сервера, но те же принципы применяются и к другим.

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

  • использование Протокол передачи файлов SSH (SFTP). Хотя использование FTP должно быть отменено для обеспечения безопасности (поскольку оно отправляет как пароли, так и содержимое в виде обычного текста), это безопасный заменитель. SFTP также имеет функцию, которая является идеальным решением для совместной разработки веб-приложений.

    После того как вы изолировали сайты и один пользователь на сайте, вам необходимо предоставить доступ к вашим веб-разработчикам, о чем этот вопрос. Вместо того, чтобы предоставлять им пароли для этих пользователей сайта - или доступ к файлам сайта с использованием их личных учетных записей пользователей, как изначально предлагалось, вы можете использовать Клавиши SSH для входа.

    Каждый разработчик может генерировать keypair и хранить секретный ключ в секрете. Затем открытый ключ добавляется к ~/.ssh/authorized_keys файл для каждой учетной записи пользователя веб-сайта, над которой работает разработчик. Это имеет много преимуществ для управления паролями и входами:

    • Каждый разработчик может иметь доступ к любому количеству веб-сайтов без бремени запоминания или хранения всех паролей, связанных с организацией пользователя на сайт.

    • Не нужно менять и делиться паролями каждый раз, когда кто-то покидает компанию.

    • Вы можете использовать очень надежные пароли или вообще отключить логин на основе пароля.

  • Использовать PHP-FPM, Это текущий подход для запуска PHP в качестве пользователя. Создать новый бассейн для каждого пользователя, то есть одного пула на каждый сайт. Это лучшее как для безопасности, так и для производительности, так как вы также можете указать, сколько ресурсов может потреблять один сайт.

    См. NeverEndingSecurity-х Запустите php-fpm с отдельным пользователем / uid и группой на linux, Есть учебники, такие как HowtoForge's Использование PHP-FPM с Apache на Ubuntu 16.04 который не использует PHP-FPM для повышения безопасности посредством разделения пользователей, направляя использование одного сокета FPM на сервере.


7
2018-05-10 10:03