[PHP] Maakt bestanden aan als root

[victorhemmings]

Ik heb zelf een webserver in een VM draaien (Debian) en ik heb zelf PHP gecompiled.
Het probleem is dat PHP runt als de gebruiker 'apache'. Hij maakt de bestanden echter aan als root. Daardoor kan PHP de bestanden daarna niet meer bewerken en kan ik ook niet bij de bestanden via mijn Samba share.
Hoe fix ik dit? Op Google kan ik hier niets over vinden.

Als ik de volgende code uitvoer:

code:

<?php
echo `whoami`;

Krijg ik als uitvoer 'apache'. Dus dat zit goed denk ik.

[frickY]

Toon de code eens die je gebruikt om een bestand aan te maken. En hoe roep je het script aan die dit doet, via je browser of commandline, als user root?

[victorhemmings]

Via de browser.

Heel vreemd, als ik gewoon de volgende code uitvoer (eerste codevoorbeeld van Google):

code:

$ourFileName = "/var/data/httpd/trunk.nl/Symfony/app/cache/testFile.txt";
$ourFileHandle = fopen($ourFileName, 'w') or die("can't open file");
fclose($ourFileHandle);
exit;

Werkt het gewoon en wordt het bestand aangemaakt met de juiste rechten.
Het probleem is dat Symfony2 cachebestanden wegschrijft in die cache map. Deze bestanden worden aangemaakt als root. Het ligt dus aan Symfony2, maar waar in de code dat gebeurt weet ik echt niet.

mkdir() ook geprobeerd en dat werkt ook gewoon.

[Verwijderd]

Jij runt als root commando's vanaf de command line.
PHP draait niet als Apache, PHP draait helemaal niet. Ja, je kunt PHP code uitvoeren via de Apache module van Apache, via CGA of FastCGI, of vanaf de command line.
Probeer dus even te begrijpen dat dit verschillende dingen zijn en dan snap je ook waarom -als je als root vanaf de command line iets aanroept- de bestanden als "root" worden aangemaakt.

[victorhemmings]

Nu begint er bij mij ook een belletje te rinkelen. Ik run commando's als root vanaf de command line, waardoor er root bestanden aan worden aangemaakt. Correct?
Dus het probleem is te verhelpen door de commando's als apache uit te voeren, toch?
Wel vreemd dat ik dit probleem bij een andere server niet had, daar was ik ook altijd als root ingelogd. Maar als dit werkt ben ik tevreden

[Verwijderd]

Dat is een manier om het te doen. Ik zou een andere manier de voorkeur geven. Als de Apache user iets moet kunnen lezen en schrijven, zou je de directories waarin dat moet kunnen chmod-en naar g+rws en kunnen chgrp-en naar de Apache user. De bestanden in die directories chmod je naar g+rw, dus niet naar g+rws (wat een enorm beveiligingsrisico zou zijn).

Als een directory de setgid bit geset heeft op de group (g+s) dan worden nieuw aangemaakte bestanden/directories daarbinnen ook automatisch van die groep. Zo mag de Apache user er schrijven, ool als je als user root iets toevoegt, want de group wordt dan de Apache group, en als die er mag schrijven is er geen probleem.

Overigens zou ik ervoor kiezen om de commando's niet als Apache-user en ook niet als root uit te voeren. Zorg ervoor dat je daarvoor een unprivileged user hebt die niet je systeem kan verknoeien. Wel zo veilig. Die user kan uiteraard lid zijn van de Apache group mocht dat nodig zijn, maar meestal is dat niet nodig.

[victorhemmings]

Thanks voor de info!
Ik ga even wat termen die je noemde Googlen en dan ga ik ermee aan de slag als ik een productieserver ga inrichten.
Dit is alleen een ontwikkelserver dus daarvoor is de bovengenoemde manier denk ik geen vereiste.

[Cartman!]

Ik zou kijken naar mod_ruid2, een module voor Apache waardoor alles wordt uitgevoerd als de user waaronder het wordt aangeroepen ipv. apache. Heb dit zelf geinstalleerd op mijn machines en vind het heel handig, geen geklooi meer met rechten van ftp-users en www/apache-users, alles gebeurt onder dezelfde username met dezelfde rechten

[kwaakvaak_v2]

hint... umask(0000); en niet je console script als root draaien.

Inloggen als root op een dev server is sowieso tikje niet nodig

[Verwijderd]

Cartman! schreef op maandag 05 november 2012 @ 14:05:
Ik zou kijken naar mod_ruid2, een module voor Apache waardoor alles wordt uitgevoerd als de user waaronder het wordt aangeroepen ipv. apache. Heb dit zelf geinstalleerd op mijn machines en vind het heel handig, geen geklooi meer met rechten van ftp-users en www/apache-users, alles gebeurt onder dezelfde username met dezelfde rechten

Wat direct ook een risico kan zijn, omdat die gebruiker meteen alle scripts kan aanpassen.

Hoe het hoort is dat er een gebruiker is die via FTP of op een andere manier (liever SFTP) scripts kan wijzigen. Er hoort ook een gebruiker te zijn waarmee de scripts vervolgens uitgevoerd kunnen worden. Vervolgens maak je deze twee gebruikers lid van dezelfde groep, waardoor je alle leesrechten kunt beperken tot de groep waarin de FTP user en WWW user zitten. Waar de WWW gebruiker mag schrijven, zet je de rechten van de directory op g+rwx (of g+rwxs), waar de WWW gebruiker niet mag schrijven op g+rx (of g+rxs).

kwaakvaak_v2 schreef op maandag 05 november 2012 @ 15:00:
hint... umask(0000); en niet je console script als root draaien.

Inloggen als root op een dev server is sowieso tikje niet nodig

Welke user moet umask 0000 doen? Als ik ooit zie dat iemand dat als root doet, trek ik gelijk zijn rechten in

[ Voor 14% gewijzigd door Verwijderd op 05-11-2012 16:28 ]

[kwaakvaak_v2]

Waar denk je dat mijn tweede opmerking op sloeg dan? Inloggen als root is eigenlijk nooit nodig op een fatsoenlijke omgeving.

Die umask is een oplossing in de symfony handleiding voor minder goed geconfigureerde machines. Symfony schrijft standaard de warmup cache vanuit de console als het console commando gebruikt. Meestal is de console user niet dezelfde user als de user waar de webserver onder draait. Bij een van onze hosting partners heeft de shell user geen toegang tot die www user data. En daar komt die umask om de hoek kijken.
De cache wordt gedeeld door die console user en de www user.