Есть ли у кого-нибудь хорошее решение для обработки файлов в /var/www? Мы используем виртуальные хосты на основе имен, а пользователь Apache 2 www-data.
У нас есть два обычных пользователя и root. Итак, когда вы возитесь с файлами в /var/wwwвместо того, чтобы ...
chown -R www-data:www-data
... все время, как лучше с этим справиться?
Дополнительный вопрос: Насколько жестко вы тогда переходите на разрешения?
Это всегда было проблемой в средах совместной разработки.
Попытка расширить @ 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 /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.
Примечание: вам нужно будет выйти / войти, чтобы изменения в ваших группах вступили в силу!
Я не совсем уверен, как вы хотите настроить разрешения, но это может дать вам отправную точку. Наверное, есть способы получше. Я предполагаю, что вы хотите, чтобы оба пользователя могли изменять что-либо в / var / www /
Это означает, что любой новый файл, созданный любым из ваших пользователей, должен иметь имя пользователя: www-pub 0664, а любой каталог, который будет создан, будет иметь имя пользователя: www-pub 2775. Apache получит доступ для чтения ко всему через компонент «другие пользователи». Бит SETGID для каталогов заставит все создаваемые файлы принадлежать группе, которой принадлежит папка. Настройка umask необходима, чтобы убедиться, что бит записи установлен так, чтобы любой член группы мог редактировать файлы.
Что касается того, насколько я хардкорен в разрешениях. Это полностью зависит от сайта / сервера. Если есть только 1-2 редактора, и мне просто нужно, чтобы они не ломали вещи слишком сильно, я буду проще. Если бизнесу требовалось что-то более сложное, я бы настроил что-то более сложное.
Я думаю, вы можете найти 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
Страницы руководства:
Этот вопрос был спросил снова, и, как обсуждали Что касается мета, то текущая передовая практика обеспечивает лучшие подходы, чем те, которые были доступны в 2009 году, когда об этом спросили. Этот ответ пытается дать некоторые текущие решения для безопасное управление средами совместной веб-разработки.
Для безопасного веб-сервера и совместной разработки есть больше, чем просто права доступа к файлам:
Иметь отдельного пользователя для каждого сайта т.е. не обслуживать все сайты, использующие www-data. Это важно, так как в настоящее время Apache редко обслуживает исключительно статический файлы содержимого, но работающие динамичный веб-сайты. Этот ответ сосредоточен на PHP, поскольку это наиболее общий язык сервер-сайт, но те же принципы применимы и к остальным.
Если у вас есть проблема с безопасностью на одном сайте, она может распространиться на все сайты, работающие от имени одного и того же пользователя. Злоумышленник может видеть все, что видит пользователь, включая информацию для входа в базу данных, и изменять каждый сайт, на котором у пользователя есть права на запись.
Использовать Протокол передачи файлов SSH (SFTP). Хотя от использования FTP следует отказаться в целях безопасности (поскольку он отправляет и пароли, и контент в виде обычного текста), это безопасная замена SFTP также имеет функцию, которая является идеальным решением для совместной веб-разработки.
После того, как вы изолировали сайты и по одному пользователю на сайт, вам нужно предоставить доступ вашим веб-разработчикам, о чем идет речь. Вместо того, чтобы сообщать им пароли для этих пользователей сайта или получать доступ к файлам сайта с использованием их личных учетных записей, как было предложено изначально, вы можете использовать SSH ключи для входа.
Каждый разработчик может сгенерировать пару ключей и сохранить секретный ключ в секрете. Затем открытый ключ добавляется в ~/.ssh/authorized_keys файл для каждой учетной записи пользователя веб-сайта, над которой работает разработчик. Это дает много преимуществ для управления паролями и логинами:
Каждый разработчик может иметь доступ к любому количеству веб-сайтов без необходимости запоминать или хранить все пароли, связанные с распределением пользователей по сайтам.
Нет необходимости менять и сообщать пароли каждый раз, когда кто-то уходит из компании.
Вы можете использовать очень надежные пароли или вообще отключить вход на основе пароля.
Используйте PHP-FPM. Это текущий подход к запуску PHP от имени пользователя. Создать новый бассейн для каждого пользователя, т.е. по одному пулу на каждый сайт. Это лучший вариант как для безопасности, так и для производительности, поскольку вы также можете указать, сколько ресурсов может потреблять один сайт.
См. Например NeverEndingSecurity's Запустите php-fpm с отдельным пользователем / uid и группой в linux. Есть учебники, такие как HowtoForge's Использование PHP-FPM с Apache в Ubuntu 16.04 который не использует PHP-FPM для повышения безопасности за счет разделения пользователей, рекомендуя использовать один сокет FPM на сервере.