Zugriffsrechte (Apache) - Versionsgeschichte

Bernd: chown-user-files.sh gibt es nicht meht

2019-11-10T19:35:26Z

chown-user-files.sh gibt es nicht meht

← Nächstältere Version		Version vom 10. November 2019, 21:35 Uhr
Zeile 13:		Zeile 13:
	Da wir diese Vorstellung nicht gut finden, haben wir uns zu folgendem Sicherheits-Konzept entschieden:		Da wir diese Vorstellung nicht gut finden, haben wir uns zu folgendem Sicherheits-Konzept entschieden:

	===PHP als FastCGI===		===PHP als FastCGI/FPM===

	PHP läuft bei schokokeks.org als FastCGI-Programm. Damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup in etwa die Geschwindigkeit eines Apache-Moduls aber mit wesentlich flexibleren Einstellungen.		PHP läuft bei schokokeks.org als FastCGI-Programm bzw. als FPM-Pool. Damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup in etwa die Geschwindigkeit eines Apache-Moduls aber mit wesentlich flexibleren Einstellungen.

	===CGI===		===CGI===
Zeile 44:		Zeile 44:

	Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.		Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.

	~~==Dateien, die plötzlich dem Benutzer "apache" gehören==~~

	Durch PHP, aber auch durch WebDAV, Subversion oder ähnliches kann es passieren, dass im eigenen Home-Verzeichnis Dateien abgelegt werden, die dem Benutzer "apache" gehören und die man daher nicht mehr selbst ändern oder löschen kann.

	~~Für solche Zwecke haben wir ein Programm erstellt, das sämtliche Dateien in einem bestimmten Verzeichnis dem betreffenden Benutzer überträgt:~~

	~~Im aktuellen Verzeichnis:~~
	~~/usr/local/bin/chown-user-files.sh~~
	~~oder alternativ mit Angabe eines bestimmten Verzeichnisses:~~
	~~/usr/local/bin/chown-user-files.sh /home/bernd/websites/foobar.com~~

Bernd am 19. Januar 2012 um 10:29 Uhr

2012-01-19T10:29:03Z

← Nächstältere Version		Version vom 19. Januar 2012, 12:29 Uhr
Zeile 15:		Zeile 15:
	===PHP als FastCGI===		===PHP als FastCGI===

	PHP läuft ~~normal~~ als FastCGI-Programm. Damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup in etwa die Geschwindigkeit eines Apache-Moduls aber mit wesentlich flexibleren Einstellungen.		PHP läuft bei schokokeks.org als FastCGI-Programm. Damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup in etwa die Geschwindigkeit eines Apache-Moduls aber mit wesentlich flexibleren Einstellungen.

	~~===PHP als Apache-Modul===~~

	Altenativ (auf Anfrage) kann PHP auch als Apache-Modul genutzt werden. In Einzelfällen kann dies die Performance erhöhen. Dann werden PHP-Scripte weiterhin als Benutzer '''apache''' ausgeführt und unterliegen den oben genannten Problemen.

	Damit das nicht so ist, vewenden wir für das Apache-Modul den safe_mode und die open_basedir-Einschränkung. Dadurch können mit einem PHP-Script nur Dateien geöffnet werden, die dem gleichen Systembenutzer gehören wie das laufende Script. mit der open_basedir-Einschränkung wird zudem für jede Domain festgelegt, wie weit ein Script im Verzeichnisbaum nach oben gehen darf. Wenn dort z.B. ''/home/bernd'' steht, darf das Script nur Dateien innerhalb des Verzeichnisses ''/home/bernd'' lesen und schreiben. Natürlich auch dort nur die, die für den Systembenutzer '''apache''' les- bzw. schreibbar sind.

	===CGI===		===CGI===

Bernd am 17. Februar 2009 um 18:06 Uhr

2009-02-17T18:06:21Z

← Nächstältere Version		Version vom 17. Februar 2009, 20:06 Uhr
Zeile 13:		Zeile 13:
	Da wir diese Vorstellung nicht gut finden, haben wir uns zu folgendem Sicherheits-Konzept entschieden:		Da wir diese Vorstellung nicht gut finden, haben wir uns zu folgendem Sicherheits-Konzept entschieden:

	===PHP===		===PHP als FastCGI===

	PHP läuft als ~~Apache-Modul und daher weitehin als Benutzer '''apache''' und zwar aus Performance~~-~~Gründen~~. Damit ~~läuft er automatich~~ ebenfalls unter der Benutzerkennung ~~'''apache'''~~. ~~Dadurch wäre laut oben genanntem Problem der Zugriff auf Dateien anderer Leute möglich~~.		PHP läuft normal als FastCGI-Programm. Damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup in etwa die Geschwindigkeit eines Apache-Moduls aber mit wesentlich flexibleren Einstellungen.

	~~Damit das nicht so ist, vewenden wir den safe_mode und die open_basedir-Einschränkung. Dadurch können mit einem~~ PHP-Script nur Dateien geöffnet werden, die dem gleichen Systembenutzer gehören wie das laufende Script. mit der open_basedir-Einschränkung wird zudem für jede Domain festgelegt, wie weit ein Script im Verzeichnisbaum nach oben gehen darf. Wenn dort z.B. ''/home/bernd'' steht, darf das Script nur Dateien innerhalb des Verzeichnisses ''/home/bernd'' lesen und schreiben. Natürlich auch dort nur die, die für den Systembenutzer '''apache''' les- bzw. schreibbar sind.		===PHP als Apache-Modul===

	~~===~~PHP als ~~CGI===~~		Altenativ (auf Anfrage) kann PHP auch als Apache-Modul genutzt werden. In Einzelfällen kann dies die Performance erhöhen. Dann werden PHP-Scripte weiterhin als Benutzer '''apache''' ausgeführt und unterliegen den oben genannten Problemen.

	~~Sollte ein~~ PHP-Script ~~benutzt~~ werden, das mit ''~~safe_mode~~'' ~~nicht arbeiten kann~~, ~~so kann für eine Domain auch PHP als FastCGI-Programm benutzt werden. damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung~~ des ~~Eigentümers auszuführen~~. ~~Durch~~ die ~~Verwendung von FastCGI erreicht dieses Setup beinahe~~ die ~~Geschwindigkeit des Apache~~-~~Moduls~~. ~~Sie können im Webinterface selbst auswählen, welche Methode Sie bevorzugen~~.		Damit das nicht so ist, vewenden wir für das Apache-Modul den safe_mode und die open_basedir-Einschränkung. Dadurch können mit einem PHP-Script nur Dateien geöffnet werden, die dem gleichen Systembenutzer gehören wie das laufende Script. mit der open_basedir-Einschränkung wird zudem für jede Domain festgelegt, wie weit ein Script im Verzeichnisbaum nach oben gehen darf. Wenn dort z.B. ''/home/bernd'' steht, darf das Script nur Dateien innerhalb des Verzeichnisses ''/home/bernd'' lesen und schreiben. Natürlich auch dort nur die, die für den Systembenutzer '''apache''' les- bzw. schreibbar sind.

	===CGI===		===CGI===

Mitja: Verlinkung ACL-Abschnitt im Artikel Unix Zugriffsrechte

2008-12-01T21:35:21Z

Verlinkung ACL-Abschnitt im Artikel Unix Zugriffsrechte

← Nächstältere Version		Version vom 1. Dezember 2008, 23:35 Uhr
Zeile 35:		Zeile 35:
	Da im Benutzer-Verzeichnis sowohl Mails gelagert werden als auch die Websites, sollte man die Zugriffsrechte des Benutzers '''apache''' sinnvoll einrichten. Dazu gehört z.B. auch, dass der Benutzer '''apache''' nur auf die Dateien Zugriff hat, auf die er Zugriff haben soll.		Da im Benutzer-Verzeichnis sowohl Mails gelagert werden als auch die Websites, sollte man die Zugriffsrechte des Benutzers '''apache''' sinnvoll einrichten. Dazu gehört z.B. auch, dass der Benutzer '''apache''' nur auf die Dateien Zugriff hat, auf die er Zugriff haben soll.

	Um diese Rechte gezielt regeln zu können, verwenden wir ACLs (''Access Control Lists''). Um dem Webserver den Zugriff auf das Verzeichnis ''/home/bernd/websites'' zu gestatten, werden folgende Befehle verwendet:		Um diese Rechte gezielt regeln zu können, verwenden wir [[Unix_Zugriffsrechte#ACL (Access Control Lists)\|ACLs (''Access Control Lists'')]]. Um dem Webserver den Zugriff auf das Verzeichnis ''/home/bernd/websites'' zu gestatten, werden folgende Befehle verwendet:

	setfacl -m u:apache:x /home/bernd /home/bernd/websites		setfacl -m u:apache:x /home/bernd /home/bernd/websites
Zeile 50:		Zeile 50:

	Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.		Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.


	==Dateien, die plötzlich dem Benutzer "apache" gehören==		==Dateien, die plötzlich dem Benutzer "apache" gehören==

Bernd am 16. Juli 2008 um 06:14 Uhr

2008-07-16T06:14:36Z

← Nächstältere Version		Version vom 16. Juli 2008, 08:14 Uhr
Zeile 50:		Zeile 50:

	Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.		Mit dem Befehl '''getfacl <Datei oder Verzeichnis>''' kann man sich die aktuelle ACL anschauen.


			==Dateien, die plötzlich dem Benutzer "apache" gehören==

			Durch PHP, aber auch durch WebDAV, Subversion oder ähnliches kann es passieren, dass im eigenen Home-Verzeichnis Dateien abgelegt werden, die dem Benutzer "apache" gehören und die man daher nicht mehr selbst ändern oder löschen kann.

			Für solche Zwecke haben wir ein Programm erstellt, das sämtliche Dateien in einem bestimmten Verzeichnis dem betreffenden Benutzer überträgt:

			Im aktuellen Verzeichnis:
			/usr/local/bin/chown-user-files.sh
			oder alternativ mit Angabe eines bestimmten Verzeichnisses:
			/usr/local/bin/chown-user-files.sh /home/bernd/websites/foobar.com

Bernd am 1. Dezember 2007 um 06:10 Uhr

2007-12-01T06:10:12Z

← Nächstältere Version		Version vom 1. Dezember 2007, 08:10 Uhr
Zeile 21:		Zeile 21:
	===PHP als CGI===		===PHP als CGI===

	Sollte ein PHP-Script benutzt werden, das mit ''safe_mode'' nicht arbeiten kann, so kann für eine Domain auch PHP als ~~CGI~~-Programm benutzt werden, damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. ~~Diese Variante~~ erreicht ~~nicht~~ die ~~Performance~~ des Apache-~~Modules und belastet den Server stärker~~. ~~Eine Enrichtung des CGI-Aufrufs wird daher von den Administratoren nur auf Antrag und nach Prüfung anderer Möglichkeiten erfolgen~~.		Sollte ein PHP-Script benutzt werden, das mit ''safe_mode'' nicht arbeiten kann, so kann für eine Domain auch PHP als FastCGI-Programm benutzt werden. damit wird es möglich, PHP-Scripts ebenfalls wie CGI-Programme (s. unten) mittels SuExec unter der Benutzerkennung des Eigentümers auszuführen. Durch die Verwendung von FastCGI erreicht dieses Setup beinahe die Geschwindigkeit des Apache-Moduls. Sie können im Webinterface selbst auswählen, welche Methode Sie bevorzugen.

	===CGI===		===CGI===

84.147.31.159: /* CGI */

2006-12-13T20:14:59Z

CGI

← Nächstältere Version		Version vom 13. Dezember 2006, 22:14 Uhr
Zeile 27:		Zeile 27:
	Für Scripte, die nach dem ''Common Gateway Interface'' vom Webserver ausgeführt werden, verwenden wir '''SuExec'''. Ein CGI kann technisch aus jedem beliebigen Script- oder Programmtyp bestehen. Damit ist es möglich, eigene Programme (binaries) oder Scripte in beliebigen, installierten Scriptsprachen (z.B. Perl, Python, Bash) zu schreiben.		Für Scripte, die nach dem ''Common Gateway Interface'' vom Webserver ausgeführt werden, verwenden wir '''SuExec'''. Ein CGI kann technisch aus jedem beliebigen Script- oder Programmtyp bestehen. Damit ist es möglich, eigene Programme (binaries) oder Scripte in beliebigen, installierten Scriptsprachen (z.B. Perl, Python, Bash) zu schreiben.

	Durch '''SuExec''' werden diese Programme dann immer unter dem ~~Systembneutzer~~ ausgeführt, den wir in der Konfiguration für die jeweilige Domain angeben. Das bedeutet, jedes CGI läuft unter dem Account des Benutzers, dem die Domain unter der es läuft, gehört.		Durch '''SuExec''' werden diese Programme dann immer unter dem Systembenutzer ausgeführt, den wir in der Konfiguration für die jeweilige Domain angeben. Das bedeutet, jedes CGI läuft unter dem Account des Benutzers, dem die Domain unter der es läuft, gehört.

	Mit diesen Einschränkungen wird wirksam verhindert, dass ein Benutzer die Daten anderer Benutzer lesen oder gar schreiben kann.		Mit diesen Einschränkungen wird wirksam verhindert, dass ein Benutzer die Daten anderer Benutzer lesen oder gar schreiben kann.

84.147.31.159: /* CGI */

2006-12-13T20:14:20Z

CGI

← Nächstältere Version		Version vom 13. Dezember 2006, 22:14 Uhr
Zeile 25:		Zeile 25:
	===CGI===		===CGI===

	Für Scripte, die nach dem ''Common Gateway Interface'' vom Webserver ausgeführt werden, verwenden wir '''SuExec'''. Ein CGI kann technisch aus jedem ~~belibigen~~ Script- oder Programmtyp bestehen. Damit ist es möglich, eigene Programme (binaries) oder Scripte in beliebigen, installierten Scriptsprachen (z.B. Perl, Python, Bash) zu schreiben.		Für Scripte, die nach dem ''Common Gateway Interface'' vom Webserver ausgeführt werden, verwenden wir '''SuExec'''. Ein CGI kann technisch aus jedem beliebigen Script- oder Programmtyp bestehen. Damit ist es möglich, eigene Programme (binaries) oder Scripte in beliebigen, installierten Scriptsprachen (z.B. Perl, Python, Bash) zu schreiben.

	Durch '''SuExec''' werden diese Programme dann immer unter dem Systembneutzer ausgeführt, den wir in der Konfiguration für die jeweilige Domain angeben. Das bedeutet, jedes CGI läuft unter dem Account des Benutzers, dem die Domain unter der es läuft, gehört.		Durch '''SuExec''' werden diese Programme dann immer unter dem Systembneutzer ausgeführt, den wir in der Konfiguration für die jeweilige Domain angeben. Das bedeutet, jedes CGI läuft unter dem Account des Benutzers, dem die Domain unter der es läuft, gehört.

Lars am 19. November 2006 um 00:34 Uhr

2006-11-19T00:34:10Z

← Nächstältere Version		Version vom 19. November 2006, 02:34 Uhr
Zeile 1:		Zeile 1:
	[[Category:Webserver]]		[[Category:Webserver]]
	[[Category:~~Dateirechte~~]]		[[Category:Zugriffsrechte]]
	Beim Betrieb eines Webservers besteht immer eine Gratwanderung zwischen zu starker Einschränkung (sodass manche Websites nicht mehr funktionieren) und zu großer Gefahr für die restlichen Daten auf dem Server.		Beim Betrieb eines Webservers besteht immer eine Gratwanderung zwischen zu starker Einschränkung (sodass manche Websites nicht mehr funktionieren) und zu großer Gefahr für die restlichen Daten auf dem Server.

Lars: Webserver-Zugriffsrechte wurde nach Zugriffsrechte (Apache) verschoben

2006-03-20T12:28:55Z

Webserver-Zugriffsrechte wurde nach Zugriffsrechte (Apache) verschoben

← Nächstältere Version	Version vom 20. März 2006, 14:28 Uhr
(kein Unterschied)