nicht angemeldet
Tach!
angenommen auf einem apache (v2.4) sollen zwei oder mehr verschiedene user jeweils mind. einen virtuellen host pflegen koennen. wie setzt man da am besten welche rechte?
Wenn die beiden nicht derselbe Kunde oder dasselbe Projekt sind, trennt man sie besser so weit wie es geht. Also Variante 4. Soweit ich weiß, kann der Apache von Haus aus aber nur mit einen Nutzer auf die VHosts zugreifen. Somit kann jeder bei jedem lesen. Bei statischen Dateien, die sowieso 1:1 zu den Clients durchgereicht werden, ist das kein Problem. Dateien mit Passwörtern und ähnlich geschäftskritischen Dingen sollten so nicht lesbar sein. Die Frage ist dann, wie bekommt man den Apachen dazu, separat unter festgelegte Nutzerkennungen zu agieren? Eine Lösung ist, PHP (und ähnliches) unter FCGI oder PHP-FPM laufen zu lassen.
AUf den Seiten von HowToForge finden sich Anleitungen für eine Menge gängiger Liunux-Distributionen zu "The Perfect Server" mit ISPConfig. Das ist eine Software für kleine Hosting-Provider mit Kundenverwaltung. Jeder Kunde bekommt eine Gruppe, jede Website eine Userkennung und ist Mitglied der Kundengruppe. So kann man zumindest auch noch innerhalb der Gruppe einen gemeinsamen Datenzugriff haben.
Das weit verbreitete Plesk geht (leider) nach Variante 1 vor, alle Kunden sind in derselben Gruppe. Man kann aber separate Nutzer für Websites vergeben. Damit hat man eine Trennung, aber kann nicht kundenseparat auf gemeinsame Dateien zugreifen. Dafür müssten zwei Websites unter derselben Kennung laufen.
Bei der Recherche fand ich auch noch, dass es (mindestens) eine einbaubare Lösung für den Apachen gibt, auch Nicht-CGI-Geschichten über eine eigene Nutzerkennung laufen zu lassen: Wie der Zufall so will, war es eine HowToForge-Anleitung mit mpm-itk. Ich hab nicht gesucht, ob es dort weitere Anleitungen für andere Distributionen gibt, aber meist machen die das für mehrere.
Im Apachen selbst gibt es auch noch mod_suexec, aber das behandelt nur (F)CGI-Programme.
Übrigens gibt es neben facl auch noch attr (lsattr, chattr), mit dem man neben anderem einige Berechtigungsschweinereien machen kann. So setzt beispielsweise ISPConfig das i(mmutable)-Bit auf das Kunden-Root-Verzeichnis, und hebt das nur für das DocumentRoot und ein private-Verzeichnis auf. Wenn man eigene nicht im Web zugängliche Verzeichnisse anlegen möchte, muss man das i entfernen (lassen vom root) oder sich unterhalb vom private ausbreiten.
dedlfix.
seth