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

215

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

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

chown -R www-data:www-data

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

Дополнительный вопрос: Насколько жестким вы тогда получаете разрешения?

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

Gareth
источник

Ответы:

206

Попытка расширить ответ @ Zoredache , как я сам попробую :

  • Создайте новую группу (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 = установить идентификатор группы, 7 = rwx для владельца (root), 7 = rwx для группы (www-pub), 5 = rx для мира (включая пользователя apache www-data)

    Бит установки идентификатора группы ( 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.

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

Том
источник
6
@ Tom Рад видеть, что вы рекомендуете использовать findкоманду для этого. Один небольшой совет по производительности, который я хотел бы дать, если у вас много файлов / каталогов и вы используете GNU find, - это использовать +вместо \;так, чтобы команда работала с несколькими файлами, потому что «быстрее выполнить команду с максимально возможным количеством файлов» за раз, а не один раз для каждого файла. Это экономит время, необходимое для запуска команды каждый раз. " Кроме того, его легче набирать, поскольку он не требует обратной косой черты.
aculich
2
Обновлено с @ aculich предложением использовать + not \;
Том
1
@SunnyJ. попробуйте это (без внешних кавычек): "find / var / www -type f -exec chmod 0664 '{}' \ +" Попробуйте это. Между '{}' и \ + есть пробел.
Баттл Буткус
1
почему мы должны дать разрешение другим увидеть и выполнить.
Кевин Паркер
1
@ Том - спасибо, спасибо. Просто примечание - я думаю, что «SETUID (4) для копирования идентификатора пользователя», как указано в вашем ответе, является неправильным - SETUID игнорируется при применении к каталогам в Linux / Unix - Ссылка
Ярин
60

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

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

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

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

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

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

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

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

Справочные страницы:

Руководство

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

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


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

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

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

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

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

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

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

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

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

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

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

Эса Йокинен
источник