Po pierwsze, ważna jest kwestia, która wpływa na sposób podejścia do niezbędnej konfiguracji:
Apache będzie obsługiwał tylko zawartość statyczną z tych miejsc (oznacza to brak witryn „dynamicznych”, które umożliwiają przesyłanie oraz brak stron podobnych do CMS, które zapisują własne pliki dziennika lub pliki tymczasowe itp.).
W tym przypadku dostęp tylko do odczytu dla Apache jest OK.
Użytkownicy chcą prowadzić witryny dynamiczne ( CGIi bardziej zaawansowane rzeczy).
W takim przypadku Apache musi zapisywać niektóre miejsca w hierarchii.
Teraz są możliwości:
Po prostu spraw, aby niezbędne hierarchie były czytelne (i możliwe do przejścia - dla katalogów) dla wszystkich.
Oczywiście działa to tylko w przypadku treści tylko do odczytu (a więc statycznej).
W takim przypadku po prostu upewnij się, że katalogi, które mają być obsługiwane, mają a=rxuprawnienia, a pliki w nich mają a=ruprawnienia - to znaczy, że użytkownicy inni niż należący do właściciela i grupy będą mogli przeglądać katalogi i odczytywać w nich pliki.
Pamiętaj, że dzięki temu „wyeksportowane” rzeczy będą czytelne dla wszystkich, nie tylko Apache, i może to stanowić problem z bezpieczeństwem.
Jak sugeruje wiki Apache , utwórz oddzielną grupę, uruchom Apache z jego GID i upewnij się, że ta grupa ma odpowiedni dostęp (R / O lub R / W w stosownych przypadkach) do zasobów.
W rzeczywistości Debian ma już tę grupę www-data, więc możesz po prostu dodać użytkowników do tej grupy. Oczywistym minusem jest to, że automatycznie uzyskają dostęp do innych zasobów należących do www-datagrupy.
Użyj separacji uprawnień za pomocą mpm-itklub innego podejścia. Pozwala to na obsługę rzeczy dla poszczególnych użytkowników z uprawnieniami dla poszczególnych użytkowników (proces menedżera apache działa, rootale procesy spawnujące odradzają się z poświadczeniami określonych użytkowników.
Nie jestem jednak pewien, czy dobrze by to grało mod_userdir.
Rozważ użycie list ACL POSIX w celu zaimplementowania bardziej szczegółowej kontroli dostępu do tych katalogów.
