Какие полномочия мои файлы/папки веб-сайта должны иметь на веб-сервере Linux?
Вот мое мнение о корректном способе выполнить это, и не значительно трудно, если все, что Вы хотите сделать, отослано почта для php через сервер SMTP Вашего ISP.
Удостоверьтесь, чтобы Вам установили MTA на Вашем экземпляре человечности, мое предпочтение является постфиксом, но можно использовать другой (exim, qmail оба прекрасны), однако некоторые из этих инструкций должны будут быть адаптированы/отдельно исследуемые, если Вы сделаете.
# apt-get install postfix postfix-doc
Затем мы должны будем сказать это, как отослать почту в интернет-использование, Вы - smtp сервер isp, у Вас должна уже быть эта информация, это может упоминаться как Ваш сервер Исходящей почты, заменить smtp.isp.net этой информацией.
# postconf -e relayhost=smtp.isp.net
Это скорректирует Ваш постфикс main.cf конфигурационный файл, чтобы позволить Вашему почтовому серверу отправить к внешнему миру.
Теперь мы должны отредактировать php.ini, чтобы сказать этому местоположение sendmail двоичного файла, этим двоичным файлом не является на самом деле sendmail MTA, но обертка для постфикса, который обеспечивает известный последовательный подобный sendmail интерфейс.
По умолчанию в debian/ubuntu постфикс sendmail двоичный файл находится в /usr/sbin/sendmail.
# whereis sendmail
Поможет Вам определять местоположение его.
Теперь, когда у нас есть полный путь для sendmail двоичного файла, мы можем отредактировать файл php.ini, он должен быть расположен в /etc/php5/apache2/php.ini, открыть его в любом редакторе, с которым Вы знакомы.
Найдите отмеченный раздел [mail function] и прокомментируйте SMTP и smtp_port директивы.
Некомментарий sendmail_path и добавьте полный путь к sendmail двоичному файлу непосредственно после = знак.
Затем выпустите это
# /etc/init.d/postfix restart
# /etc/init.d/apache2 restart
Затем попытайтесь отправить сообщение от сценария PHP, если это перестало работать, проверяют/var/log/mail.info файл.
Решая, какие разрешения использовать, вы должны точно знать, кто ваши пользователи и что им нужно. Веб-сервер взаимодействует с двумя типами пользователей.
Аутентифицированные пользователи имеют учетную запись на сервере и могут иметь определенные привилегии. Обычно сюда входят системные администраторы, разработчики и учетные записи служб. Обычно они вносят изменения в систему, используя SSH или SFTP.
Анонимные пользователи - это посетители вашего веб-сайта. Хотя у них нет разрешений на прямой доступ к файлам, они могут запрашивать веб-страницу, и веб-сервер действует от их имени. Вы можете ограничить доступ анонимных пользователей, внимательно следя за тем, какие разрешения есть у процесса веб-сервера. Во многих дистрибутивах Linux Apache работает как пользователь www-data , но это может быть другое. Используйте ps aux | grep httpd или ps aux | grep apache , чтобы узнать, какого пользователя Apache использует в вашей системе.
Примечания о разрешениях Linux
Linux и другие POSIX-совместимые системы используют традиционные разрешения unix. В Википедии есть отличная статья о разрешениях файловой системы , поэтому я не буду здесь все повторять. Но есть несколько вещей, о которых вам следует знать.
Бит выполнения
Интерпретируемые скрипты (например, Ruby, PHP) отлично работают без разрешения на выполнение. Бит выполнения нужен только для двоичных файлов и сценариев оболочки. Чтобы пройти (войти) в каталог, вам необходимо иметь разрешение на выполнение в этом каталоге. Веб-серверу необходимо это разрешение для отображения каталога или обслуживания любых файлов внутри него.
Разрешения для новых файлов по умолчанию
Когда файл создается, обычно он наследует идентификатор группы того, кто ее создал. Но иногда вы хотите, чтобы новые файлы наследовали идентификатор группы папки, в которой они были созданы, поэтому вы можете включить бит SGID в родительской папке.
Значения разрешений по умолчанию зависят от вашей umask. Umask вычитает разрешения из вновь созданных файлов, поэтому общее значение 022 приводит к созданию файлов с 755. При совместной работе с группой полезно изменить вашу umask на 002, чтобы файлы, которые вы создавали, могли быть изменены членами группы. А если вы хотите настроить разрешения для загружаемых файлов, вам нужно либо изменить umask для apache, либо запустить chmod после загрузки файла.
Проблема с 777
Когда вы chmod 777 ваш сайт, у вас нет никакой безопасности. Любой пользователь в системе может изменить или удалить любой файл на вашем сайте. Но если серьезно, помните, что веб-сервер действует от имени посетителей вашего веб-сайта, и теперь веб-сервер может изменять те же файлы, которые он выполняет. Если на вашем веб-сайте есть программные уязвимости, они могут быть использованы для искажения вашего веб-сайта, фишинговых атак или кражи информации с вашего сервера без вашего ведома.
Кроме того, если ваш сервер работает на хорошо - известный порт (который должен препятствовать тому, чтобы пользователи без полномочий root создавали службы прослушивания, доступные всем), это означает, что ваш сервер должен быть запущен с правами root (хотя любой нормальный сервер сразу перейдет к менее привилегированной учетной записи один раз порт привязан). Другими словами, если вы установите их как владельца пользователя в каталоге веб-сайта и предоставьте пользователю полные разрешения rwx. Apache все еще нужен доступ, чтобы он мог обслуживать файлы, поэтому установите www-data в качестве владельца группы и дайте группе разрешения rx.
В вашем случае, Ева, имя пользователя которой может быть eve , является единственный пользователь, обслуживающий contoso.com :
chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/
ls -l
drwxr-s--- 2 eve www-data 4096 Feb 5 22:52 contoso.com
Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете просто изменить значения разрешений для владельца группы, чтобы www-data имел доступ на запись.
chmod g+w uploads
ls -l
drwxrws--- 2 eve www-data 4096 Feb 5 22:52 uploads
Преимущество этой конфигурации состоит в том, что другим пользователям в системе становится труднее (но не невозможно *) «следить», поскольку только пользователи и владельцы групп могут просматривать каталог вашего веб-сайта. Это полезно, если у вас есть секретные данные в ваших файлах конфигурации. Будьте осторожны со своей маской! Если вы создадите здесь новый файл, значения разрешений, вероятно, будут по умолчанию равны 755. Вы можете запустить umask 027 , чтобы по умолчанию для новых файлов было 640 ( rw- r-- --- ).
Поддерживается a группа пользователей
Если за обслуживание сайта отвечают несколько пользователей, вам нужно будет создать группу, которая будет использоваться для назначения разрешений. Хорошая практика - создать отдельную группу для каждого веб-сайта и называть группу после этого веб-сайта.
groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob
В предыдущем примере мы использовали владельца группы, чтобы предоставить привилегии Apache, но теперь это используется для группы разработчиков. Поскольку пользователь-владелец нам больше не нужен, установка для него root - простой способ гарантировать, что никакие привилегии не утекут. Apache по-прежнему нуждается в доступе, поэтому мы даем доступ для чтения остальному миру.
chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com
ls -l
drwxrwxr-x 2 root dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Если у вас есть папки, в которые Apache должен делать запись, вы можете сделать Apache либо владельцем пользователя, либо владельцем группы. В любом случае у него будет весь необходимый доступ. Лично я предпочитаю сделать его владельцем пользователя, чтобы разработчики по-прежнему могли просматривать и изменять содержимое папок загрузки.
chown -R www-data uploads
ls -l
drwxrwxr-x 2 www-data dev-fabrikam 4096 Feb 5 22:52 uploads
Хотя это распространенный подход, у него есть обратная сторона. Поскольку все остальные пользователи системы имеют те же права доступа к вашему веб-сайту, что и Apache, другие пользователи могут легко просматривать ваш сайт и читать файлы, которые могут содержать секретные данные, такие как файлы конфигурации.
Вы можете получить свой торт. и съесть это тоже
Это можно улучшить. Совершенно законно, чтобы владелец имел меньше привилегий, чем группа, поэтому вместо того, чтобы тратить зря владельца пользователя, назначая его root, мы можем сделать Apache владельцем пользователя для каталогов и файлов на вашем веб-сайте. Это противоположность сценария с одним сопровождающим, но он работает одинаково хорошо.
chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com
ls -l
dr-xrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете просто изменить значения разрешений для пользователя-владельца, чтобы www-data имел доступ на запись .
chmod u+w uploads
ls -l
drwxrwx--- 2 www-data dev-fabrikam 4096 Feb 5 22:52 fabrikam.com
При использовании этого решения следует быть осторожным с тем, что пользователь-владелец новых файлов будет соответствовать создателю, а не использовать www-data. Таким образом, любые новые файлы, которые вы создаете, не будут доступны для чтения Apache, пока вы не загрузите их.
* Разделение привилегий Apache
Я упоминал ранее, что на самом деле другие пользователи могут следить за вашим сайтом независимо от того, какие у вас права Пользуюсь. По умолчанию все процессы Apache запускаются от имени одного и того же пользователя www-data, поэтому любой процесс Apache может читать файлы со всех других веб-сайтов, настроенных на том же сервере, а иногда даже вносить изменения. Любой пользователь, который может заставить Apache запускать сценарий, может получить тот же доступ, что и сам Apache.
Для решения этой проблемы существуют различные подходы к разделению привилегий в Apache. Однако каждый подход имеет свои недостатки в производительности и безопасности. На мой взгляд, любой сайт с более высокими требованиями к безопасности следует запускать на выделенном сервере вместо использования VirtualHosts на общем сервере.
Дополнительные соображения
Я не упоминал об этом раньше, но обычно иметь разработчики, редактирующие сайт напрямую. Для более крупных сайтов вам гораздо лучше иметь какую-то систему выпуска, которая обновляет веб-сервер из содержимого системы контроля версий. Подход с одним сопровождающим, вероятно, идеален, но вместо человека вы автоматизировали программное обеспечение.
Если на вашем веб-сайте разрешены загрузки, которые не нужно обслуживать, эти загрузки следует хранить где-то за пределами корневого веб-сайта. В противном случае вы можете обнаружить, что люди загружают файлы, которые должны были быть секретными. Например, если вы разрешаете учащимся отправлять задания, они должны быть сохранены в каталог, который не обслуживается Apache. Это также хороший подход для файлов конфигурации, которые содержат секреты.
Для веб-сайта с более сложными требованиями вы можете изучить использование списков контроля доступа . Это обеспечивает более сложный контроль над привилегиями.
Если ваш веб-сайт имеет сложные требования, вы можете написать сценарий, который устанавливает все разрешения. Тщательно проверьте его, а затем сохраните.
Учитывая рейтинг Google в приведенном выше превосходном ответе, я думаю, что есть одна вещь, которую следует отметить, и я не могу оставить записку после ответа.
Продолжая с Например, если вы планируете использовать www-data в качестве владельца и dev-fabrikam в качестве группы с 570 разрешениями на каталог (или файл), важно отметить, что Linux игнорирует setuid , поэтому все новые файлы будут принадлежать пользователю, который их создал. Это означает, что после создания новых каталогов и файлов вам придется использовать что-то похожее на:
chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/
В Ubuntu 12.04 для Rackspace OpenStack у меня была странная проблема, когда я не мог получить разрешения 570 для работы, пока я не перезагрузил сервер, что волшебным образом исправил проблему. Выпадал волосы все чаще из-за этой, казалось бы, простой проблемы ....
I'm wondering why so many people use (or recommend) the "other" (o) part of the Linux rights to control what can do Apache (and/or PHP). By setting this right part to something else than "0", you just allow the whole world to do something on the file/directory.
My approach is following:
- I create two separated users. One for the SSH/SFTP access (if needed), which will own all the files, and one for the PHP FastCGI user (the user the website will run as). Let's call these users respectively bob and bob-www.
- bob will have full rights (rwx on folders, rw- on files), so that he/she can read and edit the whole website.
- The PHP FastCGI process needs r-x rights on folders and r-- rights on files, except for very specific folders like
cache/oruploads/, where the "write" permission is also needed. To give PHP FastCGI this ability, it will run as bob-www, and bob-www will be added to the automatically created bob group. - We now make sure the owner and group of all directories and files are bob bob.
- Something is missing : even we use FastCGI, but Apache still needs read access, for static content, or .htaccess files that it will try to read if
AllowOverrideis set to something else thanNone. To avoid using the o part of the rights, I add the www-data user to the bob group.
Now:
- To control what the developer can do, we can play with the u part of the rights (but this the note below).
- To control what Apache and PHP can do, we can play with the g part of the rights.
- The o part is always set to 0, so nobody else on the server can read or edit the website.
- There is no problem when bob user creates new files, since it will automatically belong to its main group (bob).
This is a recap, but in this situation, bob is allowed to SSH. If there shouldn't be any user allowed to modify the website (eg. customer only modifies the website through a CMS admin panel and doesn't have Linux knowledge), create two users anyway, but give /bin/false as shell for bob as well, and disable its login.
adduser --home /var/www/bobwebsite --shell /bin/bash bob
adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
adduser www-data bob
cd /var/www/bobwebsite
chown -R bob:bob .
find -type d -exec chmod 750 {} \;
find -type f -exec chmod 640 {} \;
Note : people tend to forget that limiting the u (owner) rights is most of the time useless and insecure, since the owner of a file can run the chmod command, even the rights are 000.
Tell me if my approach has some security issues, because I'm not 100% sure, but it is what I'm using.
I think this config has a problem : when PHP/Apache creates a new file (eg. upload), it will belong to bob-www:bob, and bob will only be able to read it. Maybe setuid on the directory can solve the problem.
I going with this configuration:
- All directories except uploads one set to owner
rootand grouproot, permissions to0755. - All files set to owner
rootand grouproot, permissions to0644. - Uploads directory set to owner
root, groupwww-data, permissions to1770. The sticky bit doesn't let group owner to remove or rename the directory and files inside. - Inside uploads folder a new directory with
www-dataowner user and group, and0700permissions for eachwww-datauser that upload files. - Apache configuration:
Deny AllowOverride and Index in uploads directory, so that Apache doesn't read .htaccess files, and Apache user can't index the content of uploads folder:
<Directory /siteDir>
Options -Indexes
</Directory>
<Directory /siteDir/uploadDir>
AllowOverride none
</Directory>
6. php.ini configuration:
open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20
With this configuration, the www-data user won't be able to get inside directories other than siteDir/ /tmp and /usr/share/phpmyadmin. Also you can control the maximum file size, the maximum post size and the maximum files to upload in the same request.