Hi,
ich hab bei mir Tobias' seine PHP-Anmeldung mal ausprobiert und es funktioniert. Was noch blöd war, das keine Daten zurückgeliefert wurden.
--- anmeldung.php3 Fri Mar 10 22:51:05 2000 +++ anmeldung.phtml Fri Mar 10 22:47:44 2000 @@ -4,4 +4,5 @@ $value = $text; dbminsert($fd,$key,$value); dbmclose($fd); + echo "<HTML><BODY>\nIhre Angaben wurden registriert.</BODY></HTML>" ?>
Außerdem blöd ist das mit dem chown nobody.
1. Kann ich das als user nicht, und per ftp auf lug-dd.schlittermann.de schon gar nicht. 2. Zweitens kann dann evtl. jeder andere mit nobody-CGI/PHP auf meine Scripte zugreifen. 3. Und für da mir die Datei anmeldung.db auch noch gehört, muss ich für Nobody auch noch Schreibrechte für alle setzen.
Gibts auch sowas wie SUIDExec für PHP ? In der php3.ini hab ich leider nichts gefunden und 'ne ./configure-Option ala Apache gibts auch nicht. (zumindest bei php-3.0.7)
Bye, Stephan
Hallo,
Außerdem blöd ist das mit dem chown nobody.
- Kann ich das als user nicht, und per ftp auf lug-dd.schlittermann.de schon gar nicht.
- Zweitens kann dann evtl. jeder andere mit nobody-CGI/PHP auf meine Scripte zugreifen.
- Und für da mir die Datei anmeldung.db auch noch gehört, muss ich für Nobody auch noch Schreibrechte für alle setzen.
Gibts auch sowas wie SUIDExec für PHP ? In der php3.ini hab ich leider nichts gefunden und 'ne ./configure-Option ala Apache gibts auch nicht. (zumindest bei php-3.0.7)
Weiß ich ehrlich gesagt auch nicht, wäre aber wünschenswert...
Aber frag doch mal Heiko, seine Kunden schicken ihm doch sicher auch php3-Scripte, die niemand anders ausführen soll.
Ciao, Tobias -- Software is like sex: It's better when it's free Linus Torvalds
__________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de
On Fri, Mar 10, 2000 at 10:48:19PM +0100, Stephan Goetter wrote: : : Gibts auch sowas wie SUIDExec für PHP ? : In der php3.ini hab ich leider nichts gefunden und 'ne ./configure-Option ala Apache gibts auch nicht. : (zumindest bei php-3.0.7)
Ich kann fuer den virtual host lug-dd eintragen, dass er als user lug-dd laeuft. Das waere doch, was Du brauchst, oder? Dann muessen/koennen alle Files lug-dd gehoeren und die sache ist relativ sauber geloest.
Heiko
Am Son, 12 Mär 2000 schrieb Heiko Schlittermann:
Ich kann fuer den virtual host lug-dd eintragen, dass er als user lug-dd laeuft.
Ich werde aus diesem Satz nicht schlau... Könntest du das etwas näher erläutern?
Ciao, Tobias -- Software is like sex: It's better when it's free Linus Torvalds
__________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de
On Fri, Mar 10, 2000 at 02:24:42PM +0100, Tobias Koenig wrote:
Am Son, 12 Mär 2000 schrieb Heiko Schlittermann:
Ich kann fuer den virtual host lug-dd eintragen, dass er als user lug-dd laeuft.
Ich werde aus diesem Satz nicht schlau... Könntest du das etwas näher erläutern?
Apache Doku lesen, speziell http://www.apache.org/docs/vhosts/index.html
Reinhard
Am Fre, 10 Mär 2000 schrieb Tobias Koenig:
Ich kann fuer den virtual host lug-dd eintragen, dass er als user lug-dd laeuft.
Ich werde aus diesem Satz nicht schlau... Könntest du das etwas näher erläutern?
# VirtualHost: Allows the daemon to respond to requests for more than one # server address, if your server machine is configured to accept IP packets # for multiple addresses. This can be accomplished with the ifconfig # alias flag, or through kernel patches like VIF.
# Any httpd.conf or srm.conf directive may go into a VirtualHost command. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # See also the BindAddress entry.
#<VirtualHost host.some_domain.com> #ServerAdmin webmaster@host.some_domain.com #DocumentRoot /www/docs/host.some_domain.com #ServerName host.some_domain.com #ErrorLog logs/host.some_domain.com-error_log #TransferLog logs/host.some_domain.com-access_log #</VirtualHost>
Bye, Stephan
Ich hab mal in der PHP3-FAQ nachgesehen. Wenn PHP als Apache-Modul läuft, funktioniert suExec nicht! Man kann dies nur umgehen, wenn man den PHP Interpreter extern aufruft.
Eine andere Möglichkeit
Zitat aus dem PHP3-Manual: -8<--------------------------------------------------- A very secure option is to put the PHP parser binary somewhere outside of the web tree of files. In /usr/local/bin, for example. The only real downside to this option is that you will now have to put a line similar to:
#!/usr/local/bin/php
as the first line of any file containing PHP tags. You will also need to make the file executable. That is, treat it exactly as you would treat any other CGI script written in Perl or sh or any other common scripting language which uses the #! shell-escape mechanism for launching itself. -8<---------------------------------------------------
Um dem Apache das Modul für den Virtuellen Host ab- zugewöhnen, hilft:
php3_engine off
im Abschnitt des <Virtual Host>.
Dann läuft alles wie normales CGI, also auch mit suExec.
Ich hoffe das hilft euch weiter.
CU Jan
On Sun, Mar 12, 2000 at 05:04:16PM +0100, Stephan Goetter wrote: : Am Fre, 10 Mär 2000 schrieb Tobias Koenig: : > > Ich kann fuer den virtual host lug-dd eintragen, dass er als user lug-dd : > > laeuft. : > Ich werde aus diesem Satz nicht schlau... : > Könntest du das etwas näher erläutern?
Das Originalproblem war die UID/GID mit der der PHP-Script laeuft, oder liege ich jetzt falsch?
. CGI-Scripte werden mit der UID/GID des Webservers ausgefuehrt, normalerweise wwwrun oder www-data (oder was aehnliches, je nach Distribution).
. Wenn mann fuer einen Virtual-Host (und lug-dd.schlittermann.de ist nichts anderes) die User lug-dd.schlittermann.de Group ftpguest Direktiven in der httpd.conf eintraegt, dann werden (bei Erfuellung einiger Nebenbedingungen) die CGI-Scripte und auch saemtliche Zugriffe auf Ressourcen (Files usw.) mit UID und GID gemaess der Konfiguration innerhalb des virtuallen Hosts getaetigt.
: # Any httpd.conf or srm.conf directive may go into a VirtualHost command. : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ja, _ANY_ unter Erfuellung einiger Randbedingungen (man muss sich letztenendes doch die Texte zu den einzelnen Direktiven durchlesen ;-))
Heiko
Heiko Schlittermann wrote:
Das Originalproblem war die UID/GID mit der der PHP-Script laeuft, oder liege ich jetzt falsch?
. CGI-Scripte werden mit der UID/GID des Webservers ausgefuehrt, normalerweise wwwrun oder www-data (oder was aehnliches, je nach Distribution).
Das funktioniert leider nur, wenn ein externes Programm mit setuid/setgid aufgerufen wird, wenn man jedoch Apache-Module verwendet (PHP), klappt das nicht. Bei mir bleibt PHP immer nobody (wie mein Apache), auch wenn in der VHost- Konfiguration andere User und Group Einträge stehen.
CU Jan
On Sun, Mar 12, 2000 at 11:37:50PM +0100, Jan Dittberner wrote: : Das funktioniert leider nur, wenn ein externes Programm mit setuid/setgid : aufgerufen wird, wenn man jedoch Apache-Module verwendet (PHP), klappt das : nicht.
: Bei mir bleibt PHP immer nobody (wie mein Apache), auch wenn in der VHost- : Konfiguration andere User und Group Einträge stehen.
Ich denke, das koennte daran liegen, dass Dein Apache nicht mit suEXEC - Support laeuft. (Das schreibt er beim Start in seine globale error.log rein.) suEXEC wrapper enabled, oder so aehnlich.
Best regards from Dresden/Germany Viele Gruesse aus Dresden Heiko Schlittermann
Heiko Schlittermann wrote:
: Bei mir bleibt PHP immer nobody (wie mein Apache), auch wenn in der VHost- : Konfiguration andere User und Group Einträge stehen.
Ich denke, das koennte daran liegen, dass Dein Apache nicht mit suEXEC - Support laeuft. (Das schreibt er beim Start in seine globale error.log rein.) suEXEC wrapper enabled, oder so aehnlich.
Also der Apache läuft selbstverständlich mit suEXEC, aber der funktioniert nur bei externen Programmen, z.B. CGI-Programmen in C.
Diese laufen dann auch unter der ID ihres Owners.
CU Jan
On Mon, Mar 13, 2000 at 04:43:14PM +0100, Jan Dittberner wrote: : Heiko Schlittermann wrote: : > : Bei mir bleibt PHP immer nobody (wie mein Apache), auch wenn in der VHost- : > : Konfiguration andere User und Group Einträge stehen. : > : > Ich denke, das koennte daran liegen, dass Dein Apache nicht mit suEXEC - : > Support laeuft. (Das schreibt er beim Start in seine globale error.log : > rein.) suEXEC wrapper enabled, oder so aehnlich. : : Also der Apache läuft selbstverständlich mit suEXEC, aber der funktioniert : nur bei externen Programmen, z.B. CGI-Programmen in C. : : Diese laufen dann auch unter der ID ihres Owners.
Hm. Aber Du magst Recht haben, denn fuer `interne' Programme kann er das suexec-Binary ja nicht nutzen.
Waere trotzdem nuetzlich, wenn er intern auch die UID/GID eines anderen annehmen koennte.
Heiko
Am Mon, 13 Mär 2000 schrieb Heiko Schlittermann:
Hm. Aber Du magst Recht haben, denn fuer `interne' Programme kann er das suexec-Binary ja nicht nutzen.
Waere trotzdem nuetzlich, wenn er intern auch die UID/GID eines anderen annehmen koennte.
Stimmt, so etwas vermisse ich bei php leider. So kann jeder z.B. auf eine Passwortdatenbank zugreifen, die ein Script zur Passwortabfrage benötigt. Notfalls, könnte man über die chmod()-Funktion von php3 nach jedem Lesen der Passwortdatei das Lesen durch 'chmod u-r' verbieten. Als sicher kann man das aber nicht gerade bezeichnen...
Ciao, Tobias
P.S. Vielen Dank für das FeedBack bezüglich Virtual Hosts bei Apache -- Software is like sex: It's better when it's free Linus Torvalds
__________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de Yahoo! Auktionen - gleich ausprobieren - http://auktionen.yahoo.de
Am Mon, 13 Mär 2000 schrieb Heiko Schlittermann:
Hm. Aber Du magst Recht haben, denn fuer `interne' Programme kann er das suexec-Binary ja nicht nutzen. Waere trotzdem nuetzlich, wenn er intern auch die UID/GID eines anderen annehmen koennte.
Wobei Jan's Lösung nicht unbedingt der Performance gut tun würde, wenn jedesmal PHP ala CGI gestartet würde, da die normale Modullösung ja FastCGI-ähnlich ist.
Das gilt natürlich nur dort wo Performance eine Rolle spielt.
Bye, Stephan
On Mon, Mar 13, 2000 at 08:11:28PM +0100, Stephan Goetter wrote: : Am Mon, 13 Mär 2000 schrieb Heiko Schlittermann: : > Hm. Aber Du magst Recht haben, denn fuer `interne' Programme kann er : > das suexec-Binary ja nicht nutzen. : > Waere trotzdem nuetzlich, wenn er intern auch die UID/GID eines anderen : > annehmen koennte. : : Wobei Jan's Lösung nicht unbedingt der Performance gut tun würde, wenn jedesmal : PHP ala CGI gestartet würde, da die normale Modullösung ja FastCGI-ähnlich ist. : : Das gilt natürlich nur dort wo Performance eine Rolle spielt.
Ist wahrscheinlich hier nicht der Fall.
Heiko
lug-dd@mailman.schlittermann.de
-
Heiko Schlittermann -
Jan Dittberner -
Reinhard Foerster -
Stephan Goetter -
Tobias Koenig