Директория /var/www принадлежит root:root, что означает, что никто не может ее использовать и она совершенно бесполезна. Поскольку мы все хотим, чтобы веб-сервер действительно работал (и никто не должен входить в систему под именем "root"), то нам нужно это исправить.
Доступ нужен только двум сущностям.
PHP/Perl/Ruby/Python нуждаются в доступе к папкам и файлам, поскольку они создают их множество (например, /uploads/). Эти скриптовые языки должны работать под nginx или apache (или даже под чем-то другим, например, FastCGI для PHP).
Я знаю, что 777 — это полное разрешение на чтение/запись/исполнение для владельца/группы/гостей. Так что это не кажется правильным, поскольку дает случайным пользователям полные разрешения.
Какие разрешения нужно использовать на /var/www, чтобы:
Обеспечить контроль исходных текстов, например, для git или svn.
Пользователям в группе типа "websites" (или даже добавленные в "www-data").
Серверы типа apache или lighthttpd и PHP/Perl/Ruby.
Которые могут читать, создавать и запускать файлы (и каталоги) там?
Если я правильно понимаю, скрипты Ruby и PHP не "выполняются" напрямую — они передаются интерпретатору. Поэтому нет необходимости в разрешении execute для файлов в /var/www...? Поэтому кажется, что правильным разрешением будет chmod -R 1660, которое сделает все файлы, доступные для совместного использования этими четырьмя сущностями.
Правильно ли это?
Дополнение 1: Я только что понял, что файлы и каталоги могут нуждаться в разных разрешениях — я говорил о файлах выше, поэтому я не уверен, какими должны быть разрешения для каталогов.
Дополнение 2: Структура папок /var/www сильно меняется, поскольку одна из четырех вышеупомянутых сущностей постоянно добавляет (и иногда удаляет) папки и подпапки на много уровней вглубь. Они также создают и удаляют файлы, доступ к которым на чтение/запись может понадобиться другим трем сущностям. Поэтому разрешения должны выполнять четыре вышеуказанные функции как для файлов, так и для каталогов. Поскольку ни одному из них не нужно разрешение, я бы предположил, что разрешение rw-rw-r-- — это все, что нужно, и это совершенно безопасно, поскольку эти четыре сущности управляются доверенными лицами, а все остальные пользователи в системе имеют доступ только на чтение.
Дополнение 3: Для персональных машин для разработки и частных серверов компании. Никаких случайных "веб-клиентов", как на общем хосте.
Дополнение 4: Я (кажется), наконец-то, нашел способ заставить все это работать. Однако я не знаю, является ли это правильным и безопасным способом сделать это. Поэтому я объявил конкурс. Победит тот, кто предложит лучший способ защиты и управления www-директорией.
Ответ 1
После долгих исследований кажется, что другим (возможно, лучшим) ответом на этот вопрос будет настройка папки www следующим образом:
sudo usermod -a -G developer user1 (добавьте каждого пользователя в группу разработчиков);
sudo chgrp -R developer /var/www/site.com/, чтобы разработчики могли там работать;
sudo chmod -R 2774 /var/www/site.com/, чтобы только разработчики могли создавать/редактировать файлы (остальные могут читать);
sudo chgrp -R www-data /var/www/site.com/uploads, чтобы www-data (apache/nginx) мог создавать загрузки.
Поскольку git запускается от имени любого пользователя, то, пока пользователь входит в группу "developer", он должен иметь возможность создавать папки, редактировать PHP-файлы и управлять репозиторием git.
Примечание: В шаге (3): '2' в 2774 означает "установить ID группы" для каталога. Это приводит к тому, что новые файлы и подкаталоги, созданные в нем, наследуют ID группы родительского каталога (вместо основной группы пользователя).
Ответ 2
Я не уверен, что это "правильно", но вот что я делаю на своем сервере:
/var/www содержит папку для каждого сайта.
Каждый сайт имеет назначенного владельца, который устанавливается как владелец всех файлов и папок в каталоге сайта.
Все пользователи, которые поддерживают сайт, объединяются в группу для этого сайта.
Эта группа назначается владельцем всех файлов и папок в каталоге.
Любые файлы и папки, которые должны быть записаны веб-сервером (т. е. PHP), имеют владельца www-data, пользователя, под которым работает apache.
Помните, что для каталогов должен быть включен бит execute, чтобы можно было просмотреть их содержимое.
Ответ 3
После проведения дополнительных исследований выяснилось, что инструменты git/svn НЕ являются проблемой, поскольку они запускаются под тем пользователем, который их использует (однако демоны git/svn — это совсем другое дело!). Все, что я создавал/клонировал с помощью git, имело мои права доступа, а инструмент git был указан в /usr/bin, что соответствует этому тезису.
Разрешения git доступны.
Разрешения пользователей, похоже, можно обеспечить, добавив всех пользователей, которым нужен доступ к каталогу www, в группу www-data, от имени которой работает apache (и nginx). Итак, похоже, что один из ответов на этот вопрос выглядит следующим образом:
По умолчанию /var/www принадлежит root:root, и никто не может добавлять или изменять там файлы.
1) Изменить владельца группы
Сначала нам нужно изменить группу каталога www так, чтобы она принадлежала группе "www-data", а не группе "root".
sudo chgrp -R www-data /var/www
2) Добавить пользователей в www-data
Затем нам нужно добавить текущего пользователя (и всех остальных) в группу www-data.
sudo usermod -a -G www-data demousername
3) Изменить права доступа к каталогу www
Измените разрешения так, чтобы ТОЛЬКО владелец (root) и все пользователи из группы "www-data" могли rwx (читать/писать/исполнять) файлы и каталоги (никто другой не должен иметь к ним доступа).
sudo chmod -R 2770 /var/www
Теперь все файлы и каталоги, созданные любым пользователем, имеющим доступ (т. е. входящим в группу "www-data"), будут доступны для чтения/записи apache и, следовательно, php.
Ответ 4
Привязка — это не наследование прав доступа. Привязка каталога означает, что только владелец файла или владелец каталога может переименовать или удалить этот файл в каталоге, несмотря на то, что разрешения говорят об обратном. Таким образом, 1777 на /tmp/.
В классическом Unix нет наследования прав доступа, основанного на файловой системе, только на umask текущего процесса. В *BSD или Linux с setgid на каталоге групповое поле вновь созданных файлов будет установлено таким же, как и в родительском каталоге. Для чего-то большего вам нужно изучить ACL, с ACL "по умолчанию" на каталогах, которые позволяют вам иметь наследуемые разрешения. Вы должны начать с определения: * какие пользователи имеют доступ к системе *, какова ваша модель угроз.
Например, если вы занимаетесь веб-хостингом с несколькими клиентами и не хотите, чтобы они видели файлы друг друга, то вы можете использовать общую группу "webcusts" для всех этих пользователей и режим каталога 0705. Тогда файлы, обслуживаемые процессом веб-сервера (не в "webcusts"), будут видеть Other perms и будут разрешены; клиенты не смогут видеть файлы друг друга, а пользователи смогут работать со своими собственными файлами. Однако это означает, что, когда вы разрешаете CGI или PHP, вы должны убедиться, что процессы запускаются от имени конкретного пользователя (хорошая практика в любом случае для нескольких пользователей на одном хосте, для отчетности). В противном случае клиенты могут испортить файлы друг друга, поручив это CGI.
Однако если пользователь, выполняющий веб-сайт, совпадает с владельцем сайта, то возникают проблемы с невозможностью защитить контент от злоумышленников в случае дыры в безопасности скрипта. Именно в этом случае выделенные хосты выигрывают, так как вы можете иметь пользователя времени выполнения, отличного от владельца статического контента, и не беспокоиться о взаимодействии с другими пользователями.
Ответ 5
Владельцем файла должен быть тот, кто его создает, а группа должна быть www-data. Режим для каталогов/файлов в общем случае будет 755/644. Если для каталогов и файлов группе нужен доступ на запись, то режим будет 775/664. Предположим, что paddy является разработчиком. В целом это дает следующее:
chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;
Linux