Jakie są zalecane uprawnienia do katalogu?

145

Przygotowuję się do wdrożenia witryny Drupal 7 i nie mogę znaleźć żadnej dokumentacji na temat tego, jakie powinny być zalecane zalecane dla plików i katalogów uprawnienia dotyczące bezpieczeństwa.

Konkretnie default/files/(także podkatalogi?) settings.php, .htaccessI coś jeszcze I powinien być świadomy.

ack
źródło
1
Istnieje również odpowiedź tutaj: drupal.stackexchange.com/questions/52695/…
Bezpłatny Radykalny
Istnieje blog, który pięknie to wyjaśnia i obejmuje wszystkie jego aspekty w abstrakcyjny sposób. technologymythbuster.blogspot.com/2018/06/…
Kalpesh Popat

Odpowiedzi:

69

Twój serwer internetowy powinien być w stanie odczytać wszystkie pliki, ale nie może do nich pisać. Jeśli witryna wymaga przesyłania plików, należy zezwolić serwerowi na zapis tylko w tym jednym folderze.

Więcej informacji o tym, jak to skonfigurować, a także o niektórych rzeczach, które mogą się zdarzyć, jeśli tego nie zrobisz, jest dostępnych w dokumentach Drupal .

Paul Jones
źródło
13
Nie dotyczy to katalogu witryn / default / files, który musi być zapisywalny przez serwer WWW, w przeciwnym razie będziesz mieć mnóstwo problemów.
rooby
3
@rooby Drugie zdanie wyjaśnia to.
kenorb
14
Chociaż jest napisane „Jeśli Twoja witryna wymaga przesyłania plików”, ale nie jest to jedyny powód, dla którego możesz potrzebować dostępu do zapisu w katalogu plików. Bardzo częstym przykładem jest agregacja js / css, czyli niepowiązani użytkownicy przesyłający pliki. Inne moduły mogą również oczekiwać, że ten katalog będzie zapisywalny.
rooby
91

Ta strona z drupalem, jak wiele innych, jest bardzo długa i myląca. Ale zawiera ten post Jasona, który trafił w sedno:

Wysłany przez Jason Sale w dniu 1 listopada 2010 o 12:40

Dziękuję za napisanie tego i wszystkiego, ale wszystko, czego ja i 99% osób czytających tę stronę naprawdę chce, to lista liczb obok listy folderów.

  • /default na 755
  • /default/files w tym wszystkie podfoldery i pliki na 744 (lub 755)
  • /default/themes w tym wszystkie podfoldery i pliki na 755
  • /default/modules w tym wszystkie podfoldery i pliki na 755
  • /default/settings.phpi /default/default.settings.phpna 444
ErichBSchulz
źródło
7
Temat jest długi i mylący. Strona pasuje do rzeczywistości.
greggles,
17
... dokumentów Drupala! I dlatego należy go natychmiast zmienić na coś prostego i zrozumiałego! Zwłaszcza jeśli chodzi o bezpieczeństwo. PO PROSTU, PONIEWAŻ chodzi o bezpieczeństwo! Ponieważ należy do nas wszystkich. Zainfekowany serwer to nie tylko problem niedoświadczonego użytkownika Drupala. Jest to zatem problem nas wszystkich. Nie jest więc bardzo pomocne utrzymywanie złożonych i źle napisanych dokumentów zainspirowanych przez programistów narcissm, aby pokazać złożoność i zawiłość oraz to, jak dobrze sobie z tym radzą. Nie widzę sensu pomijanie prostej grafiki drzewa uprawnień do plików. webchick się z tym zgadza.
nilsun
3
Dlaczego 755 ma / default / files? Czy nie powinno to zawsze oznaczać 744 na wypadek, gdyby komuś udało się przesłać coś złośliwego przez zhakowanie interfejsu (lub przez złą konfigurację)? Czy jest jakiś powód, aby mieć 755? Co z / tmp?
Webdrips
1
Plik settings.php powinien mieć rozmiar 440. „Inne” nie powinny widzieć pliku settings.php. 740, jeśli chcesz mieć możliwość pisania na nim bez poleceń sudo.
Bryden,
Ciekawe, dlaczego plik .htaccess w plikach i folderze tmp musi być napisany przez serwer WWW? czy nie jest bezpiecznie oznaczyć go jako 444 jako settings.php. Powód, dla którego pytam, to czy plik hunk.php może zostać przesłany przez hakera do folderu plików za pośrednictwem serwera WWW, a następnie plik .htaccess może zostać zastąpiony. czy mam rację?
Kiranking
82

Moją praktyką związaną z tworzeniem nowej witryny Drupal na serwerze jest posiadanie użytkownika, który jest częścią grupy serwerów WWW (zazwyczaj Apache) i posiadanie przez niego wszystkich plików Drupal. W systemie Ubuntu są to polecenia umożliwiające skonfigurowanie:

# Create a new example user, setting up /var/www/example as their home dir.
useradd -s /bin/bash -d /var/www/example -m example

# Now add that user to the Apache group. On Ubuntu/Debian this group is usually
# called www-data, on CentOS it's usually apache.
usermod -a -G www-data example

# Set up a password for this user.
passwd example

Kiedy już skonfiguruję, zaloguję się jako ten użytkownik i zainstaluję Drupal na / var / www / example / docroot lub podobnym, a następnie ręcznie utworzę katalog plików i skopiuję plik settings.php. Ponieważ logujemy się jako nasz przykładowy użytkownik przed kopiowaniem w Drupal, nasza własność i uprawnienia do plików powinny być automatycznie skonfigurowane we wszystkich podstawowych plikach i skryptach Drupal (w tym .htaccess).

su - example
cd docroot
cp sites/default/default.settings.php sites/default/settings.php

# Temporarily give the web server write permissions to settings.php
chgrp www-data sites/default/settings.php
chmod g+w sites/default/settings.php

Teraz skonfigurujmy katalog plików.

# Create the directory.
mkdir sites/default/files

# Now set the group to the Apache group. -R means recursive, and -v means 
# verbose mode.
chgrp -Rv www-data sites/default/files

Następnie skonfigurujemy uprawnienia, aby serwer sieciowy zawsze mógł zapisywać do dowolnego pliku znajdującego się w tym katalogu. Robimy to za pomocą 2775 w naszym poleceniu chmod. 2 oznacza, że ​​identyfikator grupy zostanie zachowany dla wszystkich nowych plików utworzonych w tym katalogu. Oznacza to, że www - data zawsze będzie grupą na dowolnych plikach, zapewniając w ten sposób, że serwer WWW i użytkownik zawsze będą mieć uprawnienia do zapisu do wszystkich nowych plików umieszczonych w tym katalogu. Pierwsze 7 oznacza, że ​​właściciel (przykład) może R (odczyt) W (zapis) i X (wykonać) dowolne pliki tutaj. Druga 7 oznacza, że ​​grupa (www-data) może również RW i X dowolne pliki w tym katalogu. Wreszcie 5 oznacza, że ​​inni użytkownicy mogą R i X plików, ale nie mogą pisać.

 chmod 2775 sites/default/files

Jeśli w tym katalogu są jakieś pliki, upewnij się, że serwer WWW ma na nich uprawnienia do zapisu.

 chmod g+w -R sites/default/files

Teraz Drupal jest gotowy do instalacji. Po zakończeniu BARDZO ważne jest, aby wrócić do settings.php i upewnić się, że wszyscy użytkownicy mają tylko uprawnienia do odczytu.

 chmod 444 sites/default/settings.php

Otóż ​​to! Ta konfiguracja pozwala uniknąć sytuacji, w których użytkownik będący właścicielem katalogu lub serwer WWW nie może zapisywać / zmieniać / usuwać plików w katalogu plików.

q0rban
źródło
czy nie jest bezpiecznie ustawić .htacess na 444 jsut jako settings.php? w każdym razie plik ten jest rzadko aktualizowany w rdzeniu Drupala.
Kiranking
Możesz ustawić .htaccess na 444, ale spowoduje to dodatkowy ból głowy podczas aktualizacji rdzenia Drupal i nie zwiększy bezpieczeństwa twojej strony.
q0rban
30

Serwer plików powinien zapisywać folder plików Drupal. Najbezpieczniejszym sposobem na to jest zmiana grupy i umożliwienie jej zapisywania w grupie, w następujący sposób:

chgrp www-data sites/default/files
chmod g+w sites/default/files

Pomijając folder przesyłania plików, najbezpieczniejszym jest chmod 644 dla wszystkich plików, 755 dla katalogów.

Można to zrobić w następujący sposób (po uruchomieniu w folderze witryny Drupal, .jest to dla bieżącej ścieżki):

find . -type f | xargs chmod 644
find . -type d | xargs chmod 755

Pamiętaj, że będziesz musiał ustawić chmod g+wponownie po uruchomieniu powyższego polecenia, ponieważ zresetują one chmod na wszystkich plikach i folderach.

mikl
źródło
2
Ta odpowiedź zakłada: jesteś na Ubuntu. Twoja witryna jest jedyną działającą na tym serwerze. Rozwiązuje on również problem tylko raz, zamiast sprawić, by stało się to automatycznie (np. Poprzez zmianę umask).
greggles,
Niekoniecznie Ubuntu, i nadal jest to pomocne, nawet jeśli na tym samym serwerze działa wiele witryn. Zmiana umask (która powinna mieć już te ustawienia) nie jest czymś, co poleciłbym osobom niezbyt dobrze zorientowanym w Linuksie. Wiem, że to nie jest doskonałe bezpieczeństwo, ale nie pozwólmy, aby doskonały był tutaj wrogiem dobra.
mikl
Na wielu stronach uruchamiam chgrp -R www-data sites/*/filesi chmod -R g+w sites/*/filespozbywam się błędów strony statusu.
leymannx
20

Jakakolwiek rada dla „chmod blah” lub „chown X” nie ma znaczenia bez wiedzy: jaki domyślny użytkownik: grupa znajduje się w plikach i jaki użytkownik i grupy działa jako twój serwer WWW.

Drupal Docs, z którymi inni się powiązali, są dość dobre w tym temacie, ale jednym z zasobów jest moduł Security Review Module, który pomaga upewnić się, że wszystko zostało ustawione poprawnie.

Greggles
źródło
9

Odpowiem, biorąc pod uwagę przypadek, w którym pliki są tworzone na serwerze za pomocą FTP, przy użyciu poświadczeń innych niż te, pod którymi działa serwer WWW (zwykle Apache działa jak nikt / nikt). Oznacza to, że użytkownik, który jest właścicielem plików utworzonych ręcznie przed uruchomieniem instalatora Drupal (który obejmuje również pliki przesłane na serwer z archiwum Drupal), nie jest użytkownikiem używanym do uruchomienia serwera WWW (ani nazwa użytkownika, ani grupa nie są zgodne) . Ten scenariusz dotyczy również przypadku, gdy pliki te są tworzone przy użyciu protokołu SSH.

  • Plik settings.php musi być zapisywalny z instalatora Drupal, ale po zakończeniu instalacji sugeruje się uczynienie go tylko do odczytu (instalator to sugeruje, a Drupal okresowo sprawdza, czy plik jest tylko do odczytu). W opisywanym przeze mnie scenariuszu uprawnienie do tego pliku powinno wynosić co najmniej 644.
  • Pliki .htaccess (które są obecne w co najmniej dwóch miejscach) powinny mieć uprawnienia 644. Użytkownik, który utworzył ten plik, powinien nadal mieć możliwość zastąpienia pliku, w przypadku gdy następna wersja Drupal zawiera plik .htaccess, który został zaktualizowany (zdarzyło się to już raz, gdy dodano wiersz do tego pliku, aby uniknąć problemu z bezpieczeństwem). Możliwe jest również ustawienie uprawnień na 444, ale w takim przypadku uprawnienia należy zmienić z powrotem na 644, gdy plik wymaga aktualizacji.
  • Katalog zawierający pliki utworzone przez moduły ( default/fileskatalog) musi być (dla użytkownika przypisanego do procesów serwera WWW, który jest następnie użytkownikiem przypisanym do skryptów PHP działających na tym serwerze):
    • czytelny
    • zapisywalny
    • przejście (moduły muszą być w stanie dotrzeć default/files/<directory-used-by-the-module>/<sub-directory-used-by-the-module>)
kiamlaluno
źródło
po przeczytaniu wątku na drupal.org/node/244924, a konkretnie drupal.org/node/244924#comment-8186447, żadna z różnych metod nie zapewniała sposobu przesyłania plików, które mają tylko 660 RW-RW ---- tj. bez bitu wykonania. Czy to nie jest główny problem bezpieczeństwa?
kiranking
8

Zalecane uprawnienia do plików / katalogów:

  • Webroot Drupal powinien być czytelny na całym świecie (patrz: updater.inc ): 0755
  • dla publicznych katalogów przesyłania: 0755 lub 0775
  • dla prywatnych katalogów przesyłania: 0750 lub 0770
  • dla przesyłanych plików publicznych: 0644 lub 0664
  • dla przesłanych prywatnych plików: 0640 lub 0660
  • dla .htaccess w katalogach przesyłania (patrz: file_create_htaccess () ): 0444 (domyślnie) lub 0644
  • dla settings.php tylko do odczytu dla wszystkich (i innych poufnych plików): 0440
  • dla wszystkich innych katalogów internetowych: 0755
  • dla wszystkich innych plików internetowych: 0644

Zalecane prawo własności do pliku / katalogu:

  • właścicielem wszystkich katalogów / plików do przesyłania należy ustawić użytkownika Apache,
  • właściciel wszystkich katalogów / plików WWW / źródeł powinien być ustawiony na użytkownika innego niż Apache,
  • (opcjonalnie) grupa wszystkich źródeł powinna być ustawiona na grupę Apache,

Oto zmienne, które kontrolują domyślne uprawnienia katalogu / pliku dla nowych elementów:

file_chmod_directory: 0775
file_chmod_file: 0664

Oto skrypt do ustawiania uprawnień: fix-permissions.sh


Czytaj więcej:


Oto skrypt, którego używam do naprawy uprawnień na zdalnym hoście dla katalogów publicznych / prywatnych:

#!/bin/sh -e
# Script to correct public/private directory and files permissions.
[ -z "$1" ] && { echo Usage: $0 @remote.dst; exit 1; }

DST="$1" && shift
GET_HTTP_GROUP='ps axo user,group,comm | egrep "(apache|httpd)" | grep -v ^root | uniq | cut -d\  -f 1'

drush $* $DST ssh 'PUB=$(drush dd %files) && PRIV=$(drush dd %private) && AGROUP=$('"$GET_HTTP_GROUP"') && chgrp -vR $AGROUP $PUB $PRIV && chmod -vR u+rwX,g+rwX,o+rX $PUB $PRIV'

Uwaga: powyższy kod będzie próbował pobrać grupę Apache i ustawić ją na GET_HTTP_GROUPzmienną.

kenorb
źródło
bardzo ładna ściągawka, z zakładkami. Dobra robota ..
kiranking
4

Ten skrypt powłoki znajduje się na dole tej strony: https://www.drupal.org/node/244924

Uruchamiam go od czasu do czasu, aby upewnić się, że moje uprawnienia są skonfigurowane poprawnie.

#!/bin/bash
# Help menu
print_help() {
cat <<-HELP
This script is used to fix permissions of a Drupal installation
you need to provide the following arguments:
1) Path to your Drupal installation.
2) Username of the user that you want to give files/directories ownership.
3) HTTPD group name (defaults to www-data for Apache).
Usage: (sudo) bash ${0##*/} --drupal_path=PATH --drupal_user=USER --httpd_group=GROUP
Example: (sudo) bash ${0##*/} --drupal_path=/usr/local/apache2/htdocs --drupal_user=john --httpd_group=www-data
HELP
exit 0
}
if [ $(id -u) != 0 ]; then
  printf "**************************************\n"
  printf "* Error: You must run this with sudo. *\n"
  printf "**************************************\n"
  print_help
  exit 1
fi
drupal_path=${1%/}
drupal_user=${2}
httpd_group="${3:-www-data}"
# Parse Command Line Arguments
while [ $# -gt 0 ]; do
  case "$1" in
    --drupal_path=*)
      drupal_path="${1#*=}"
      ;;
    --drupal_user=*)
      drupal_user="${1#*=}"
      ;;
    --httpd_group=*)
      httpd_group="${1#*=}"
      ;;
    --help) print_help;;
    *)
      printf "***********************************************************\n"
      printf "* Error: Invalid argument, run --help for valid arguments. *\n"
      printf "***********************************************************\n"
      exit 1
  esac
  shift
done
if [ -z "${drupal_path}" ] || [ ! -d "${drupal_path}/sites" ] || [ ! -f "${drupal_path}/core/modules/system/system.module" ] && [ ! -f "${drupal_path}/modules/system/system.module" ]; then
  printf "*********************************************\n"
  printf "* Error: Please provide a valid Drupal path. *\n"
  printf "*********************************************\n"
  print_help
  exit 1
fi
if [ -z "${drupal_user}" ] || [[ $(id -un "${drupal_user}" 2> /dev/null) != "${drupal_user}" ]]; then
  printf "*************************************\n"
  printf "* Error: Please provide a valid user. *\n"
  printf "*************************************\n"
  print_help
  exit 1
fi
cd $drupal_path
printf "Changing ownership of all contents of "${drupal_path}":\n user => "${drupal_user}" \t group => "${httpd_group}"\n"
chown -R ${drupal_user}:${httpd_group} .
printf "Changing permissions of all directories inside "${drupal_path}" to "rwxr-x---"...\n"
find . -type d -exec chmod u=rwx,g=rx,o= '{}' \;
printf "Changing permissions of all files inside "${drupal_path}" to "rw-r-----"...\n"
find . -type f -exec chmod u=rw,g=r,o= '{}' \;
printf "Changing permissions of "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
cd sites
find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
printf "Changing permissions of all files inside all "files" directories in "${drupal_path}/sites" to "rw-rw----"...\n"
printf "Changing permissions of all directories inside all "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
for x in ./*/files; do
    find ${x} -type d -exec chmod ug=rwx,o= '{}' \;
    find ${x} -type f -exec chmod ug=rw,o= '{}' \;
done
echo "Done setting proper permissions on files and directories"
Copy the code above to a file, name it "fix-permissions.sh" and run it as follows:
sudo bash fix-permissions.sh --drupal_path=your/drupal/path --drupal_user=your_user_name

Note: The server group name is assumed "www-data", if it differs use the --httpd_group=GROUP argument.
Richard Robinson
źródło
2

Również jeśli używasz fastcgi, php działa jako użytkownik i będzie miał dostęp do wszystkich plików, do których użytkownik ma dostęp, chyba że celowo spróbujesz tego uniknąć.

G.Martin
źródło
1

Pomogło mi to z problemami związanymi z uprawnieniami OSX. Znalazłem go w https://www.drupal.org/node/244924#comment-3741738 przez użytkownika protoplazmy. Byłem jak on, który ma problemy po migracji.

[root@localhost]cd /path_to_drupal_installation/sites
[root@localhost]find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
[root@localhost]find . -name files -type d -exec find '{}' -type f \; | while read FILE; do chmod ug=rw,o= "$FILE"; done
[root@localhost]find . -name files -type d -exec find '{}' -type d \; | while read DIR; do chmod ug=rwx,o= "$DIR"; done
Cayerdis
źródło
-3

Istnieje moduł o nazwie Przegląd bezpieczeństwa, który sprawdza, czy witryna jest bezpieczna, czy nie. Znalazłem również bardzo dobry link do ustawiania uprawnień do witryny.

Manikandan
źródło