PHP Script - Rechte unter userid / suphp-0.6.1

[sundriver]

Hallo @ all,

auf meinem Rootserver, SuSE9.2, Apache2.xx, PHP5.1.2, Confixx Premium, habe ich folgendes Problem das ein User zwar php Scripte ausführen kann aber im Fall diese ein Verzeichniss oder Dateien anlegen diese nochimmer dem wwwrun gehören. Nach vielem Googeln und dem befragen der SuFu hier im Board habe ich nun suphp-0.6.1 gesaugt und es mit

Code: Select all

./configure --with-apxs=/usr/sbin/apxs2-prefork --prefix=/usr --with-logfile=/var/log/apache2/suphp.log

make und einem make install installiert. Die installation verlief ohne Fehlermeldungen, das Modul mod_suphp.so wurde auch erfolgreich erzeugt und ich habe es auch erfolgreich als Apache Modul geladen. In der httpd.conf habe ich "suPHP_Engine on" auch eingetragen und den Apache mit rcapache2 restart neu gestartet. Alles ging bis hierher ohne irgendwelche Fehlermeldungen. Wenn ich mich nun jedoch als Kunde in einen Webaccount einlogge und ein PHP Script ausführe das auf diesem Account Verzeichnisse und Dateien erzeugt gehören diese nochimmer wwwrun, WAS läuft hier falsch?? Kann mir hier bitte jemand behilflich sein bzw. wie kann ich erreichen das die von den PHP Scripten erzeugten Verzeichnisse und Dateien innerhalb des Useraccountes auch dem jeweiligen Usern gehören und nicht wwwrun?? Merkwürdig ist auch das es das logfile in /var/log/apache2/suphp.log nicht gibt...
p.s. der Useraccount in diesem Fall läuft auf SafeMode off

Ich bin für jede Hilfe bzw Lösungsansatz arg Dankbar!

Thx & bye
Sundriver

[duergner]

http://www.suphp.org/Documentation-Modu ... on.en.html

Du musst suPHP schon sagen mit welchem User es arbeiten soll.

[sundriver]

Hi duergner,

danke für deine schnelle Antwort, ich scheine aber irgendwie grad mächtig auf dem Schlauch zu stehen. Die suphp.conf gab es bei mir in /etc/ nicht, ich habe dann die aus dem Installverzeichnis genommen, umbenannt und nach /etc/suphp.conf kopiert. Den Pfad zur Logdatei habe ich auch noch angepasst. die suphp.conf sieht so aus :

Code: Select all

[global]
;Path to logfile
logfile=/var/log/apache2/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=wwwrun

;Path all scripts have to be in
docroot=/

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=false

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0077

; Minimum UID
min_uid=100

; Minimum GID
min_gid=100


[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Den Befehl "suPHP_Engine on" habe ich wie geschrieben in die httpd.conf geschrieben, das Problem was ich nun grad habe ist das ich absolut nicht weis wohin ich die Konfigdaten "suPHP_UserGroup (expects user- and groupname)" bzw suPHP_ConfigPath (expects a path name), mit den richtigen Einstellungen natürlich, eintragen muss, ich denke mal die kommen in die suphp.conf, oder?

bye
Sundriver

[duergner]

Nein die kommen in den entsprechenden VHost. Wie willst du denn sonst für jeden VHost die korrekte UID/GID hinterlegen? Ist denn selbst denken wirklich so schwer?

[sundriver]

Nein die kommen in den entsprechenden VHost. Wie willst du denn sonst für jeden VHost die korrekte UID/GID hinterlegen?

O.K. das hilft mir weiter, Danke!

Ist denn selbst denken wirklich so schwer?

Ich hab mit Denken absolut kein Problem, aber hast du denn noch nie "den Wald vor lauter Bäume" nicht gesehen..

Gruß
Sundriver

[sundriver]

Hi @ all,

So, soweit ist alles gelungenermassen installiert, funktioniert aber nicht da php5 als _mod läuft und wohl auch weil beide den selben mime typ benutzen, so stehts jedenfalls im Manual. Im Fall ich php5 als PHP-CGI ausführen würde, würde es funktionieren. Die Frage ist nur ob dann noch die php_admin_values mit denen ich im Connfixx einzelne virtuelle Hosts steuern kann funktioniert. Ein erster Test auf einem vServer war wenig erfolgreich.. Gibt es hierzu Lösungen oder Lösungsansätze wo Rootserver auf Apache 2.xx , SuSE9.2, PHP5-CGI, suPHP sowie Confixx Premium erfolgreich zusammen laufen?

bye
Sundriver

[duergner]

Nein die php_admin_value Sachen gehn nur mit mod_php. Du willst suPHP_ConfigPath entsprechend setzen und halt für VHosts die eine andere als die Standard Config haben eigene modifizierte php.ini Dateien angeben.

[sundriver]

Hallo duergner,

O.K. das würde in diesem Fall bedeuten das ich jedem Webkundenverzeichnis eine eigene Modifizierte php.ini zuweisen muss da ich ja jeden User seine eigene Umgebung zuweise will in deren Grenzen er sich austoben kann. Ich müsste dann also die "open_basedir /srv/www/htdocs/web1/:/srv/www/htdocs/phpMyAdmin/:/srv/www/htdocs/confixx/html/gesperrt/" in die php.ini von User "web1" einbauen und sie via suPHP_ConfigPath zuweisen.Gut, das würde zwar ziemlich den compfort von Confixx dämpfen aber dafür das ergbnis erzielen das jedem seine Scripte unter seiner uid, in seiner Umgebung laufen.. da hab ich noch viel Arbeit... 8)

Vielen Dank erstmal

bye
Sundriver

[duergner]

Kann man das nicht in Confixx reinpatchen, dass das automatisch mit erstellt wird? Du verwendest ja hier eigentlich nur Standardwerte die sonst von Confixx in die vhosts.conf geschrieben werden.

[Joe User]

Ein wenig greppen und seden per Cron ist doch nicht schwer...

[sundriver]

Diese Idee hatte ich auch eben da es sich ja um templates handelt, so gesehen könnte ich wohl alle relevanten Dinge die in die vhost.conf kommen von Confixx erzeugen lassen aber die jeweilige php.ini muss ich selbst erstellen und in den jeweiligen vhost platzieren.Ich muss mir das erstmal an meinem Spiel und Test vServer anschauen bevor ich das an dem heissen Rootie mache. Ich hab noch so die Nase voll von vorgestern, da habe ich versucht ein pear Frontend zum verwalten eigener pear Pakete auf einem Webkundenverzeichnis zu installieren, brauch dir ja nicht sagen das das nicht funktioniert wenn alles wwwrun gehört.. So muss ich nun das ganze anders aufdröseln.

bye
Sundriver

[sundriver]

Hi Joe User,

Ein wenig greppen und seden per Cron ist doch nicht schwer...

naja, sagen wir mal so, Linux vertraut bin ich erst seit ca. 1 1/2 Jahren und Windoof hat mich nie wirklich losgelassen...

bye
Sundriver

[sundriver]

@ duergner,

es scheint noch einen anderen Weg zu geben mit den php Rechten. Ich hab noch stundenlang Google befragt und hab nun mal folgendes probiert: ich habe zusätzlich zu dem bereits installierten PHP-Modul das gleiche nocheinmal ohne --with-apxs2-prefork compiliert und dadurch ein php-cgi binary erhalten die auf /usr/bin liegt. Ein php -v zeigt :

Code: Select all

PHP 5.1.2 (cgi) (built: Apr 20 2006 13:38:10)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with Zend Extension Manager v1.0.9, Copyright (c) 2003-2006, by Zend Technologies
    with Zend Optimizer v2.6.2, Copyright (c) 1998-2006, by Zend Technologies

Danach habe ich suPHP0.5.2 installiert, nun funktioniert auch das suphp.log, und letztendlich habe ich in die virtuser.conf folgenden Eintrag gemacht:

Code: Select all

<VirtualHost xx.xx.xx.29:80>
ServerName xxxx.de
ServerAlias  www.xxxx.de web8.xxxx.de
DocumentRoot /srv/www/htdocs/web8/html
SuexecUserGroup web8 ftponly
ScriptAlias /cgi-bin/ /srv/www/htdocs/web8/html/cgi-bin/
php_admin_value open_basedir /srv/www/htdocs/web8/:/srv/www/htdocs/phpMyAdmin/:/srv/www/htdocs/confixx/html/gesperrt/
php_admin_value upload_tmp_dir /srv/www/htdocs/web8/phptmp/

php_admin_flag engine off
suPHP_Engine on
suPHP_ConfigPath /etc/web
<Directory "/usr/bin/php">
AllowOverride None
Options +ExecCGI +FollowSymLinks
Order allow,deny
Allow from all
</Directory>
ScriptAlias /php /usr/bin/php
  Action php application/php/php
  AddType application/php .php

</VirtualHost>

Durch "php_admin_flag engine off" bekomme ich keine Fehler mehr wenn Apache neu gestartet wird. Das einzige was passiert ist aber das ich nun das aufgerufene php file zum Download angeboten bekomme und suPHP nix macht, wenn ich jedoch den Handler AddType application/php .php durch AddHandler x-httpd-php .php .php3 .php4 ersetze kann die Datei nicht geladen werden lese ich im Browser und nach einem Timeout ist schluß.Aber suPHP arbeitet in diesem Fall --> Auszug aus der suPHP.log -->

Code: Select all

[Thu Apr 20 15:03:23 2006] [info] Executing /srv/www/htdocs/web8/html/phpinfo.php as user web8 (20096), group ftponly (106)

die uid / user und Group werden richtig gesetzt Hast du da eventuell noch eine Idee? Ich hab grad kein so richtigen Plan mehr, werde erstmal eine Rund mit der KiloGixxer drehen und dann versuchen weiterzu suchen.

Gruß
Sundriver

[duergner]

Ich hatte selber suPHP noch nicht im Einsatz, aber deine Action Directive sieht irgendwie ziemlich krank aus. Und IMHO fehlt dir noch der Handler dazu. So wird das zumindest bei FastCGI gemacht.

[sundriver]

Hi duergner,

Ich hatte selber suPHP noch nicht im Einsatz, aber deine Action Directive sieht irgendwie ziemlich krank aus.

ja, ich weis, ich bin das grd mehr oder weniger Intuitiv am sondieren da ich grad im moment nicht mehr viel weiter weis. Habe es grad mit

Code: Select all

<Directory "/usr/bin/php"> 
Order allow,deny 
allow from all 
Options ExecCGI 
AllowOverride None 
</Directory> 

AddType application/x-httpd-php .php 
ScriptAlias /php/ "/usr/bin/php" 
Action application/x-httpd-php "/php/php"

in vhost probiert aber auch hier keine chance.. das hier war der Eintrag in der suPHP.log :

Code: Select all

Thu Apr 20 20:44:40 2006] [info] Executing /srv/www/htdocs/web8/html/phpinfo.php as user web8 (20096), group ftponly (106)

uid richtig gesetzt user und group auch und trotzdem nix im browser ausser einem Timeout und Seite nicht gefunden... Werde mich nochmal speziell durch googlen. Ich muss erstmal rausfinden was mit der angeforderten php.datei passiert nachdem suPHP die Finger dran hatte..

Gruß
Sundriver

[duergner]

Kannst du PHP Logging mal anschalten und schaun ob da was drinnen steht? Hast du mod_php nicht geladen? Das macht ja laut der suPHP Homepage Probleme. Und die ganze ScriptAlias Sachen braucht man laut suPHP Doku gar nicht.

[sundriver]

Logging einschalten ist eine gute Idee, werde ich direkt mal machen. mod_php ist aktiv, meine Idee ist ja das so ziemlich alle vHost's ganz normal in ihrer Umgebung mit mod_php laufen und nur einige ausgewählte vHost's ihre php Scripte mit php-cgi parsen, wegen der Rechte nur ausgewählte. Ich habe auch schon überlegt mod_php temporär auszuschalten aber wenn man der suPHP Doku glaubt kollidieren mod_php und suPHP ja wegen der gleichen mime Typen, o.k. meine Idee ist wie gesagt einzelne vHost's aus der "normalen" Apache Umgebung herraus zu lösen und sie gezielt mit php-cgi zu parsen, sozusagen in ihrer eigenen Sandbox, deswegen glaube ich das es nicht an den mime Typen liegen kann aber man weis ja nie.. ich denke ich werd trotzdem mal ohne das mod_php Modul probieren. Irgendwo muss der Hund ja begraben sein.. Komisch ist auch das suexec keine error Einträge hat und das error.log vom Apachen auch nicht..

Gruß
Sundriver

[duergner]

Naja eine Alternative wäre ja auch noch, nicht mod_suphp sondern suExec zu nehmen. Dann kannst du die PHP Scripte wie ganz normale CGI Scripte behandeln. Soweit ich das Konzept von mod_suphp verstanden hab, macht es das ja irgendwie ein klein wenig anders. Evtl. kannst du auch versuchen in den bestroffenen VHosts den PHP Dateien andere MIME Typen zu verpassen.

[sundriver]

Hi duergner,

bei mir läuft suExec bereits, ich hab leider nur keine Ahnung wie ich das hinbiegen soll die Scripte als CGI Scripte zu behandeln. Fest steht jedenfalls das solange es mir nicht gelingt die Scripte nicht von mod_php parsen zu lassen das ganze nicht funktioniert. Es funktioniert nicht zusammen. Naja den vHosts andere mime Typen zu verpassen sprengt derzeit meinen Horizont ein wenig,was ich nicht möchte ist die php extensions zu ändern, etwa in php5 oder so, es sollen lediglich einzelne vhosts ausserhalb von mod_php geparst werden mit php-cgi und ich hab grad absolut keine Ahnung mehr wie ich das trennen kann. Ich denke aber das es doch möglich sein muss, es kommt eine Anfrage von einem Browser eine datei von einem bestimmten vHost zu parsen, in der vHost.conf muss es dann aber doch irgendwie möglich sein dem Apachen mitzuteilen welchen php Interpreter er nutzen soll und das Ergebniss rausschicken

hab ich grad gefunden, werd ich mal testen..

Code: Select all

3. SuPHP und Mod_PHP gemeinsam nutzen
Falls man zum Beispiel Confixx (oder andere Software, die mod_PHP benötigt) auf einem System laufen lassen will, das suPHP einsetzt, ist es nötig, mod_PHP und suPHP so einzurichten, dass sich diese beiden Apache-Erweiterungen nicht in die Quere kommen. Vorraussetzung hierzu ist, dass mod_PHP und suPHP fertig eingerichtet sind (Achtung: falls beides der Fall ist, kann es ohne diese speziellen Anpassungen zu Problemen mit PHP kommen!) Nun zu den Änderungen, die in der httpd.conf notwendig sind: Zu erst sollte man global (also außerhalb aller VHosts) suPHP aktivieren und mod_PHP abschalten. (Dabei ist zu beachten, dass einige dieser Einstellungen schon bei der mod_PHP-Installation vorgenommen wurden) 

 suPHP_Engine on
php_admin_flag engine off
AddType application/x-httpd-php .php
AddHandler x-httpd-php .php 
 

Nun braucht man nur noch suPHP in den VHosts zu deaktivieren und mod_PHP zu aktivieren, in denen man eben mod_PHP einsetzen will.

 <VirtualHost ....>
suPHP_Engine off
RemoveHandler .php
php_admin_flag engine on
</VirtualHost>
 

Qelle: http://archiv.debianhowto.de/de/suphp/suphp_modphp.html

Gruß
Sundriver