Apache права доступа linux

Пользователь и группа www-data

После установки Apache нужно установить правильные права доступа для пользователей и групп. В этом нам помогут команды chown (изменить владельца) и chmod (изменить права доступа). Рассмотрим эти команды, а потом установим владельца для директории /var/www и права доступа к ней.

В Linux существует всего три вида прав — право на чтение ( read ), запись ( write ) и выполнение ( execute ), а также три категории пользователей, к которым они могут применяться — владелец файла ( user ), группа владельца ( group ) и все остальные ( others ).

Команда chmod

Изменяет прав доступа к файлу или директории.

• Опция -R позволяет рекурсивно изменять права доступа для каталога
• Владелец — права доступа в числовом виде для владельца
• Группа — права доступа в числовом виде для группы
• Другие — права доступа в числовом виде для других

Команда chown

Изменяет владельца и/или группу файла или директории.

Опция -R — позволяет рекурсивно изменять владельца каталога.

Исходные данные

После установки web-сервера

• Apache запущен под пользователем и группой www-data
• Директории виртуальных хостов расположены в /var/www

Нам нужно обеспечить минимальные права для web-сервера (чтение директорий и файлов), чтобы он мог работать. И предоставить необходимые права на создание, редактирование и удаление файлов и директорий разработчику.

Создадим пользователя developer и назначим ему основную группу www-data :

Зададим пароль для нового пользователя:

Изменяем владельца

Устанавливаем владельца и группу для всех директорий /var/www :

Устанавливаем владельца и группу для всех файлов /var/www :

Здесь можно обойтись одной командой (но с двумя нагляднее):

Устанавливаем права

Устанавливаем права для всех директорий /var/www :

Теперь ситуация такая:

• Пользователь developer (разработчик) имеет право на чтение и запись директорий, потому что является их владельцем
• Пользователь www-data (web-сервер) имеет право на чтение директорий, потому что принадлежит к группе www-data

Устанавливаем права для всех файлов /var/www :

Теперь ситуация такая:

• Пользователь developer (разработчик) имеет право на чтение и запись файлов, потому что является их владельцем
• Пользователь www-data (web-сервер) имеет право на чтение файлов, потому что принадлежит к группе www-data

Для наглядности посмотрим на права всех файлов и директорий:

Источник

Права доступа CHMOD для пользователей и групп в Apache

Недавно мне довелось прочесывать интернет в надежде найти подробную информацию о том, как правильно выставить права доступа для пользователей и групп в Apache с помощью chmod . Что мне удалось найти:

Основы

Есть три группы прав доступа к файлам/директориям, о которых вам стоит позаботиться:

• Пользователь – что может делать владелец файла;
• Группа – что могут делать пользователи отдельных групп;
• Другие – что могут делать остальные пользователи.

У пользователей есть логины ( уникальные для каждого пользователя ). Пользователи могут быть частью группы.

Примечание: команда chmod принимает целые числа ( 0664 ), и каждая из цифр отвечает за определенные права доступа.

Сегодня я расскажу вам о том, как правильно использовать chmod-настройки . Chmod используются для изменения прав доступа к директории или файлу.

Флаги

chmod –R позволит рекурсивно пройтись по всей указанной директории и изменить права доступа для всех файлов и вложенных директорий.

Изменяем права доступа

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

Вы можете добавлять или удалять права доступа при помощи следующих команд chmod :

• + добавить права доступа;
• — удалить права доступа.

Можно задавать следующие права доступа:

Эти знания можно использовать для настройки прав доступа в Apache :

• Apache запущен как пользователь www-data в группе www-data ;
• Корневой каталог сервера: /var/www .

Для начала

Нам нужно установить владельца/группу для корневого каталога ( и любых внутренних директорий и файлов ):

Нужно установить правильные права доступа для пользователей и групп. Запускаем несколько общих команд, которые закрывают доступ, а затем открываем доступ, насколько нам требуется.

Сначала сделайте так, чтобы никто кроме текущего пользователя ( www-data ) не имел доступа к содержимому директории web-root . Мы используем ‘ go ‘, поэтому команда будет направлена к группам и другим пользователям (‘ group ‘ и ‘ other ‘). Также мы используем ‘ — ‘ для отключения прав доступа. Затем используется параметр ‘rwx ‘, чтобы запретить чтение, запись и исполнение.

Далее нужно разрешить пользователям из той же группы ( и ‘other’ ) открывать директорию /var/www . Это делается без рекурсивного подхода. Мы указываем ‘ group ‘ и ‘ other ‘, но используем параметр ‘ + ‘, чтобы разрешить исполнение ( chmod ‘x’ ).

Далее изменяем права доступа всех директорий и файлов в корневом каталоге для той же группы ( www-data ). На случай, если в ней есть файлы:

Теперь нужно произвести некоторые « сбросы ». C помощью команд chmod сделайте так, чтобы только один пользователь мог осуществлять доступ к контенту:

Сделайте так, чтобы любой пользователь из той же группы мог читать/записывать и выполнять директории и файлы в корневом каталоге на сервере:

Лично я дал группе право записывать – это нужно для тех пользователей, которые редактируют контент. Выглядит это следующим образом:

Зачастую вам даже не придется проделывать все это, но данная статья вполне способна помочь разобраться.

Источник

Какие разрешения должны иметь файлы / папки моего веб-сайта на веб-сервере Linux?

Это канонический вопрос о правах доступа к файлам на веб-сервере Linux.

У меня есть веб-сервер Linux под управлением Apache2, на котором размещены несколько веб-сайтов. У каждого сайта есть своя папка в / var / www /.

Базовый каталог / var / www / принадлежит root: root. Apache работает как www-data: www-data. Веб-сайт Fabrikam поддерживается двумя разработчиками, Алисой и Бобом. Оба сайта Contoso поддерживаются одним разработчиком, Евой. Все сайты позволяют пользователям загружать изображения. Если веб-сайт скомпрометирован, воздействие должно быть максимально ограничено.

Я хочу знать, как лучше настроить разрешения, чтобы Apache мог обслуживать контент, веб-сайт был защищен от атак, а разработчики все еще могли вносить изменения. Один из веб-сайтов имеет следующую структуру:

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

Решая, какие разрешения использовать, вы должны точно знать, кто ваши пользователи и что им нужно. Веб-сервер взаимодействует с двумя типами пользователей.

Прошедшие проверку пользователи имеют учетную запись на сервере, и им могут быть предоставлены определенные привилегии. Обычно это системные администраторы, разработчики и учетные записи служб. Они обычно вносят изменения в систему, используя 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 (хотя любой нормальный сервер будет немедленно отброшен). на менее привилегированную учетную запись, когда порт привязан). Другими словами, если вы запускаете веб-сервер, где основной исполняемый файл является частью системы управления версиями (например, приложение CGI), оставляя свои разрешения (или, в этом отношении, разрешения содержащего каталог, так как пользователь может переименовать (777) позволяет любому пользователю запускать любой исполняемый файл от имени пользователя root.

Определите требования

• Разработчикам необходим доступ на чтение и запись к файлам, чтобы они могли обновлять веб-сайт
• Разработчики должны читать / писать / выполнять каталоги, чтобы они могли просматривать
• Apache нужен доступ для чтения к файлам и интерпретируемым скриптам
• Apache нужен доступ на чтение / выполнение к обслуживаемым каталогам
• Apache нужен доступ для чтения / записи / выполнения к каталогам для загруженного контента

Поддерживается одним пользователем

Если за обслуживание сайта отвечает только один пользователь, установите его в качестве владельца пользователя в каталоге веб-сайта и предоставьте пользователю полные разрешения rwx. Apache все еще нуждается в доступе, чтобы он мог обслуживать файлы, поэтому установите www-data в качестве владельца группы и предоставьте группе разрешения rx.

В вашем случае, Eve, чье имя пользователя может быть eve , является единственным пользователем, который поддерживает contoso.com :

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

Преимущество этой конфигурации заключается в том, что другим пользователям в системе становится труднее (но не невозможно *) шпионить, поскольку только пользователи и владельцы групп могут просматривать каталог вашего веб-сайта. Это полезно, если у вас есть секретные данные в ваших файлах конфигурации. Будь осторожен с маской! Если вы создадите новый файл здесь, значения разрешений, вероятно, будут по умолчанию равны 755. Вы можете запустить, umask 027 чтобы новые файлы по умолчанию равнялись 640 ( rw- r— — ).

Поддерживается группой пользователей

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

В предыдущем примере мы использовали владельца группы для предоставления прав Apache, но теперь это используется для группы разработчиков. Поскольку владелец пользователя нам больше не нужен, установка его в root — это простой способ убедиться, что никакие привилегии не пропущены. Apache все еще нуждается в доступе, поэтому мы предоставляем доступ для чтения остальному миру.

Если у вас есть папки, которые должны быть доступны для записи Apache, вы можете сделать Apache владельцем или пользователем группы. В любом случае, у него будет все необходимое для доступа. Лично я предпочитаю сделать его владельцем, чтобы разработчики все еще могли просматривать и изменять содержимое папок загрузки.

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

Вы можете съесть свой торт и съесть его тоже

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

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

С этим решением следует быть осторожным: пользователь, которому принадлежат новые файлы, будет соответствовать создателю, а не устанавливать www-data. Поэтому любые новые файлы, которые вы создаете, не будут доступны для чтения Apache, пока вы не создадите их.

* Разделение привилегий Apache

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

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

Дополнительные соображения

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

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

Для веб-сайта с более сложными требованиями вы можете изучить использование списков контроля доступа . Это позволяет гораздо более сложный контроль над привилегиями.

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

Мне интересно, почему так много людей используют (или рекомендуют) «другую» (o) часть прав Linux, чтобы контролировать, что может делать Apache (и / или PHP). Установив для этой правой части что-то другое, чем «0», вы просто позволяете всему миру что-то делать с файлом / каталогом.

Мой подход заключается в следующем:

• Я создаю двух отдельных пользователей. Один для доступа SSH / SFTP (при необходимости), которому будут принадлежать все файлы, и один для пользователя PHP FastCGI (пользователя, от которого будет работать веб-сайт). Давайте назовем этих пользователей соответственно bob и bob-www .
• Боб будет иметь полные права ( rwx на папки, rw- на файлы), чтобы он мог читать и редактировать весь сайт.
• Процесс PHP FastCGI требует прав rx для папок и прав r- для файлов, за исключением очень специфических папок, таких как cache/ or uploads/ , где также необходимо разрешение «запись». Чтобы дать PHP FastCGI эту возможность, он будет работать как bob-www , а bob-www будет добавлен в автоматически созданную группу bob .
• Теперь мы удостоверимся, что владельцем и группой всех каталогов и файлов является bob bob .
• Чего-то не хватает: даже мы используем FastCGI, но Apache все еще нуждается в доступе для чтения, для статического содержимого или файлов .htaccess, которые он будет пытаться прочитать, если для AllowOverride него установлено другое значение None . Для того, чтобы избежать использования уплотнительной части прав, я добавляю WWW-данные пользователя в бобе группы.

В настоящее время:

• Для того, чтобы контролировать то , что разработчик может сделать, мы можем играть с ˙U части прав (но это ниже ноты).
• Для того, чтобы контролировать то , что Apache и PHP может сделать, мы можем играть с г части прав.
• Часть o всегда имеет значение 0, поэтому никто другой на сервере не может читать или редактировать веб-сайт.
• Нет проблем, когда пользователь bob создает новые файлы, так как он автоматически будет принадлежать своей основной группе ( bob ).

Это резюме, но в этой ситуации Бобу разрешен SSH. Если не должно быть пользователей, которым разрешено изменять сайт (например, клиент изменяет сайт только через административную панель CMS и не имеет знаний о Linux), в любом случае создайте двух пользователей, но также предоставьте /bin/false оболочку для bob , и отключить свой логин.

Примечание: люди склонны забывать, что ограничение прав u (владельца) в большинстве случаев бесполезно и небезопасно, поскольку владелец файла может выполнить chmod команду, даже если права равны 000.

Скажите, есть ли в моем подходе проблемы с безопасностью, потому что я не уверен на 100%, но это то, что я использую.

Я думаю, что у этого конфига есть проблема: когда PHP / Apache создает новый файл (например, upload), он будет принадлежать bob-www: bob , и bob сможет только прочитать его. Может быть, setuid в каталоге может решить проблему.

Источник