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

<p>кто-нибудь получил хорошее решение для обработки файлов в <code>/var/www</code>? мы используем виртуальные хосты на основе имен, а пользователь apache 2 <strong>www-data</strong>.</p><p>у нас есть два постоянных пользователя и root. так что когда возиться с файлами в <code>/var/www</code>, вместо того, чтобы ...</p><pre><code>chown -r www-data:www-data </code></pre><p>... все время, какой хороший способ справиться с этим?</p><p>дополнительный вопрос: насколько жестким вы тогда получаете разрешения?</p><p>это всегда было проблемой в средах совместной разработки.</p>

<p>попытка расширить на @ zoredache's <a href="https://serverfault.com/a/6899/4276">answer</a> , так как я сам попробую:</p><ul> <li> <p><em> создайте новую группу (www-pub) и добавьте пользователей в эту группу </em></p> <p><code>groupadd www-pub</code></p> <p><code>usermod -a -g www-pub usera</code> <em> ## необходимо использовать -a для добавления к существующим группам </em></p> <p><code>usermod -a -g www-pub userb</code></p> <p><code>groups usera</code> <em> ## отображать группы для пользователя </em></p> </li> <li> <p><em> измените владельца всего в/var/www на root: www-pub </em></p> <p><code>chown -r root:www-pub /var/www</code> <em> ## -r для рекурсивного </em></p> </li> <li> <p><em> измените разрешения для всех папок на 2775 </em></p> <p><code>chmod 2775 /var/www</code> <em> ## 2 = установить идентификатор группы, 7 = rwx для владельца (root), 7 = rwx для группы (www-pub), 5 = rx для мира (включая www-данные apache пользователь) </em></p> <p>установка идентификатора группы ( <a href="https://www.gnu.org/software/coreutils/manual/html\_node/directory-setuid-and-setgid.html"> setgid </a> ) bit (2) приводит к тому, что группа (www-pub) копируется во все новые файлы/папки, созданные в этой папке. другими вариантами являются setuid (4) для копирования идентификатора пользователя и sticky (1), который, я думаю, позволяет только владельцу удалять файлы.</p> <p>это <code>-r</code> рекурсивная опция, но она не будет различать файлы и папки, поэтому вы должны <a href="http://movabletripe.com/archive/recursively-chmod-directories-only/">использовать find</a> , вот так:</p> <p><code>find /var/www -type d -exec chmod 2775 {} +</code></p> </li> <li> <p><em> измените все файлы на 0664 </em></p> <p><code>find /var/www -type f -exec chmod 0664 {} +</code></p> </li> <li> <p><em> измените umask для ваших пользователей на 0002 </em></p> <p>umask управляет разрешениями на создание файлов по умолчанию, 0002 означает, что файлы будут иметь 664, а каталоги 775. установите это (отредактировав строку <code>umask</code> внизу <code>/etc/profile</code> в моем случае) означает, что файлы, созданные одним пользователем, будут доступны для записи другим пользователям в группе www без необходимости <code>chmod</code> их.</p> </li> </ul><p>проверьте все это, создав файл и каталог и проверив владельца, группу и разрешения с помощью <code>ls -l</code>.</p><p>примечание. чтобы изменения в группах вступили в силу, вам необходимо выйти из системы!</p>

<p>я не совсем уверен, как вы хотите настроить разрешения, но это может дать вам отправную точку. там, вероятно, есть лучшие способы. я предполагаю, что вы хотите, чтобы оба пользователя могли что-либо изменить в/var/www /</p><ul> <li>создайте новую группу (www-pub) и добавьте пользователей в эту группу.</li> <li>измените владельца всего в/var/www на root: www-pub.</li> <li>измените разрешения всех папок на 2775</li> <li>измените все файлы на 0664.</li> <li>измените umask для ваших пользователей на 0002</li> </ul><p>это означает, что любой новый файл, созданный любым из ваших пользователей, должен иметь имя пользователя: www-pub 0664, а любой создаваемый каталог будет именем пользователя: www-pub 2775. apache получит доступ на чтение ко всему через компонент "другие пользователи". бит setgid для каталогов заставит все созданные файлы принадлежать группе, которой принадлежит папка. настройка umask необходима для того, чтобы убедиться, что бит записи установлен так, что любой человек в группе сможет редактировать файлы.</p><p>что касается того, как хардкор я иду на разрешения. это полностью зависит от сайта/сервера. если есть только 1-2 редактора, и мне просто нужно, чтобы они не слишком сильно ломали вещи, тогда мне будет легко. если бы бизнес требовал чего-то более сложного, я бы создал что-то более сложное.</p>

<p>я думаю, что вам может пригодиться posix acl (списки контроля доступа). они допускают более детальную модель разрешений по сравнению с моделью user: group: other. я обнаружил, что их проще держать в голове, так как я могу быть более явным, а также могу установить поведение "по умолчанию" для ветви файловой системы.</p><p>например, вы можете явно указать разрешения каждого пользователя:</p><pre><code>setfacl -rm d:u:usera:rwx,u:usera:rwx /var/www setfacl -rm d:u:userb:rwx,u:userb:rwx /var/www </code></pre><p>или вы можете сделать это на основе какой-то общей группы:</p><pre><code>setfacl -rm d:g:groupa:rwx,u:groupa:rwx /var/www </code></pre><p>и, возможно, вы хотите оставить своего пользователя apache доступным только для чтения</p><pre><code>setfacl -rm d:u:www-data:rx,u:www-data:rx /var/www </code></pre><p>справочные страницы:</p><ul> <li> <a href="http://linux.die.net/man/1/setfacl">setfacl</a> </li> <li> <a href="http://linux.die.net/man/1/getfacl">getfacl</a> </li> </ul><p> <a href="http://www.cs.unc.edu/cms/help/help-articles/posix-acls-in-linux">учебное пособие</a> </p>

<p><em> этот вопрос был <a href="https://serverfault.com/questions/911187/whats-is-the-best-user-to-manage-webserver">задан снова</a> , и, как <a href="https://meta.serverfault.com/questions/9293/new-response-duplicate-of-old-question-whose-answer-is-no-longer-valid">обсуждено</a> в отношении мета, текущая передовая практика обеспечивает лучшие подходы, чем те, которые были доступны в 2009 году, когда этот вопрос задавался. этот ответ пытается дать некоторые текущие решения для <strong> безопасного управления средами совместной веб-разработки </strong>.</em></p><hr><p>для безопасного веб-сервера и совместной разработки есть больше, чем просто права доступа к файлам:</p><ul> <li> <p><strong> для каждого сайта должен быть отдельный пользователь </strong>, т. е. не обслуживать все сайты, используя <code>www-data</code>. это важно, поскольку в настоящее время apache редко обслуживает только <em> static</em> файлы содержимого, но работает <em> dynamic</em> веб-сайтов. этот ответ концентрируется на php, поскольку это <a href="https://w3techs.com/technologies/market/programming\_language/10">наиболее распространенный</a> язык сервера-сайта, но те же принципы применимы и к другим.</p> <p>если у вас есть проблема с безопасностью на одном сайте, она может распространиться на все сайты, на которых работает один и тот же пользователь. злоумышленник может видеть все, что видит пользователь, включая информацию для входа в базу данных, и изменять каждый сайт, на который у пользователя есть права на запись.</p> </li> <li> <p><strong> используйте <em> ssh file transfer protocol</em> (sftp). </strong> при использовании ftp следует отказаться от безопасности (так как он отправляет оба пароли и содержимое в виде простого текста), это безопасная замена sftp также имеет функцию, которая является идеальным решением для совместной веб-разработки.</p> <p>после того, как вы изолировали сайты и по одному пользователю на сайт, вам нужно предоставить доступ своим веб-разработчикам, о чем этот вопрос. вместо того, чтобы давать им пароли для этих пользователей сайта - или для доступа к файлам сайта, используя их личные учетные записи, как это было изначально предложено - вы можете использовать <a href="https://www.ssh.com/ssh/key/">ключи ssh</a> для входа в систему.</p> <p>каждый разработчик может создать пару ключей и сохранить секретный ключ в секрете. затем открытый ключ добавляется к <code>~/.ssh/authorized\_keys</code> файл для каждой учетной записи пользователя веб-сайта, над которой работает разработчик. это имеет много преимуществ для управления паролями и логинами:</p> <ul> <li> <p>каждый разработчик может иметь доступ к любому количеству веб-сайтов без необходимости запоминать или хранить все пароли, связанные с соглашением по каждому сайту.</p> </li> <li> <p>не нужно менять пароли и делиться ими каждый раз, когда кто-то покидает компанию.</p> </li> <li> <p>вы можете использовать очень надежные пароли или вообще отключить логин на основе пароля.</p> </li> </ul> </li> <li> <p><strong> используйте php-fpm </strong>. это текущий подход для запуска php как пользователь. создайте новый <em> пул</em> для каждого пользователя, то есть один пул на каждый сайт. это лучше всего для безопасности и производительности, так как вы также можете указать, сколько ресурсов может потреблять один сайт.</p> <p>смотрите, например neverendingsecurity's <a href="https://neverendingsecurity.wordpress.com/2015/03/14/run-php-fpm-with-separate-useruid-and-group-on-linux/">запустите php-fpm с отдельным пользователем/uid и группой в linux</a> . существуют учебные пособия, такие как howtoforge: <a href="https://www.howtoforge.com/tutorial/apache-with-php-fpm-on-ubuntu-16-04/#-configuring-apache">использование php-fpm с apache в ubuntu 16.04</a> , в которых php-fpm не используется для повышения безопасности за счет разделения пользователей, что помогает использовать один сокет fpm на сервере.</p> </li> </ul>