CHMOD rechten met PHP werken niet xxx
0826215221524
Code (php)
1
2
3
4
2
3
4
mkdir('/home/admin/domains/domain.nl/private_html/images/products/2571/0826215221524'); chmod('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524',0777);
//of
shell_exec('chmod 777 /home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524');
//of
shell_exec('chmod 777 /home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524');
of met mkdir direct 0777, werkt ook niet.
De parent DIR 2571 heeft wel 777 rechten.
Geen errors met
ini_set('display_errors',1);
error_reporting(E_ALL);
setenforce 0 heb ik op 0 gezet.
En ook met umask werkt dit niet:
$oldmask = umask(0);
mkdir("test", 0777);
umask($oldmask);
Als ik in root inlog kan ik folders met alle rechten aanmaken.
waarom werkt dit niet met de PHP code via een browser?
Toevoeging op 19/09/2019 00:17:25:
UPDATE
Desalniettemin,
ineens in deze volgorde werkt het wel:
mkdir('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524, 0777, true);
chmod('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524,0777);
Alleen het verplaatsen van deze map naar een andere
Code (php)
1
exec('mv -T -f /home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524 /home/admin/domains/domein.nl/private_html/images/products/3240/0826215221524');
Dat werkt weer niet, terwijl alle rechten 777 zijn, snap er geen bal meer van, want had gewerkt.
Het werkt alleen als root in de shell, maar niet in PHP.
Is dit wel mogelijk?
Anders moet ik het tijdelijk in een database zetten wat in een cronjob vervolgens verplaatst word.
Gewijzigd op 19/09/2019 00:21:58 door Daniel van Seggelen
En als je nu (ook) eens een soort universele root directory maakt waarin al dit soort PHP processen los kunnen gaan, dan hoef je dit ook maar op één plaats eenmalig in te stellen? Als zoiets mogelijk is natuurlijk. Dan kun je vervolgens wie wat waar mag schrijven volledig binnen PHP zelf afhandelen.
Zie bijvoorbeeld de "What to do" alinea in het volgende artikel.
User apache (www-data) moet een map aanmaken in /home/admin/
User admin (user admin) is de eigenaar van die map.
Wat jij wil is, dat www-data iets doet waar hij geen recht op heeft van admin.
En daar zit je probleem. Wat je zelf al hebt uitgevonden is dat root overal mag schrijven.
Dat klopt ook, want root is een soort van god. Die is de enige user die alles kan op je Linux server.
De simpelste maar slechtste oplossing is, om de map admin een chown te geven.
chown -R www-data.www-data /home/admin/
Dat lost je probleem wel op maar dan heb je weer een ander probleem en dat is dat user admin niets meer met die map kan doen en dat je een lek hebt omdat iedereen via apache kan lezen en schrijven in De map admin.
Ik denk dat je dit soort dingen niet via een browser moet doen.
Dan is de vraag hoe wel?
Is het een taak dat meteen uitgevoerd moet worden? Gebeurd het dagelijks?
Dan zou ik er voor kiezen om het via de commandline te doen.
Of er een simpel shell script voor te schrijven die deze taak uitvoert en dan een cronjob van maken.
O ja, chmodden is niet de oplossing... 0777 is zoiets als ik mag alles lezen, schrijven en uitvoeren van een bestand.
Daar kan je al hacker hele leuke stoute dingetjes mee doen. Niet doen dus!
Quote:
Dat lost je probleem wel op maar dan heb je weer een ander probleem en dat is dat user admin niets meer met die map kan doen
Dat hoeft niet per se een probleem te zijn. En ja, dan verplaats je verantwoordelijkheid, dus dan moet je die ook nemen :).
Quote:
en dat je een lek hebt omdat iedereen via apache kan lezen en schrijven in De map admin.
Dit is dan een potentieel nieuw probleem die je in code (in de beveiligingslaag van je applicatie maar ook daarbuiten, eigenlijk in alles waarbij "user data" komt kijken) zal moeten oplossen.
Een systeem/applicatie is zo sterk als zijn zwakste schakel, daar ontkom je niet aan.
Maar zoals @Bart aanhaalt hangt de oplossing mede of zelfs sterk af van het gedrag van deze data. Of je dit dus al dan niet via de browser zou moeten doen hangt hier dus ook van af.
Waarom trouwens in private_html? Ik zou dit ofwel in de publieke webdirectory doen, of daarbuiten. Hoe worden deze bestanden geserveerd? Gebeurt dit rechtstreeks of via code met een soort van authenticatie? Als het laatste gebeurt kun je het net zo goed buiten de webdirectory zetten?
Heb je voor deze functionaliteit van tevoren een soort van plan of ontwerp gemaakt of ben je iets on-the-fly aan het bedenken?
Quote:
ineens in deze volgorde werkt het wel:
mkdir('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524, 0777, true);
chmod('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524,0777);
Alleen het verplaatsen van deze map naar een andere
mkdir('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524, 0777, true);
chmod('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524,0777);
Alleen het verplaatsen van deze map naar een andere
Nu gebruik ik
Code (php)
1
rename('/home/admin/domains/domein.nl/private_html/images/products/2571/0826215221524','/home/admin/domains/domein.nl/private_html/images/products/3240/0826215221524');
Dit werkt nu wel (maar voor hoe lang?) en met de cron doe ik dagelijks chmod -R 777 /home/admin/domains/domein.nl/private_html/images/products.
ik wil dus de onderliggende submappen verplaatsen.
Voorheen werkte het soms via 'mv -f -T /home/admin/domains/ en nu niet meer.
Ik hoop dat dit nu blijft werken.
Je probleem zit ook niet in cp, mv mkdir e.d.
Het probleem zit hem in de user die wat mag doen.
Ik schreef eerder al:
Code (php)
1
chown -R www-data.www-data /home/admin/
Je hoeft (moet) niets te chmodden, en al zeker niet naar 777!
Dit is echt gevaarlijk!
Quote:
Dit werkt nu wel (maar voor hoe lang?) en met de cron doe ik dagelijks chmod -R 777 /home/admin/domains/domein.nl/private_html/images/products.
ik wil dus de onderliggende submappen verplaatsen.
ik wil dus de onderliggende submappen verplaatsen.
Schiet me zomaar te binnen, je wil dit allemaal met een brouwser doen toch?
Zou zomaar kunnen zijn de je over je maximale execution time gaat?
Dan zit je dus een probleem op te lossen dat niet bestaat. Immers het werkt wel, en soms ook niet.
Als daar in die mappen veel data zit dan zou ik me dat goed kunnen voorstellen dat het niet werkt en bij mindere data wel met het symptoom wat je ons verteld.
Ik/wij hier wil best even verder meedenken of het allemaal niet slimmer aangepakt kan worden, maar dan moet je ons niet het symptoom vertellen maar wat je wil bereiken en hoe jij jou applicatie voor je ziet. Dan kunnen we ook gerichter een antwoord geven.
chown -R www-data.www-data /home/admin/
de volgende foutmelding:
"chown:invalid user www-data.www-data"
Zo gevaarlijk is chmod 777 niet, als er maar 1 gebruiker is op de server en dat ben ik zelf.
Gewijzigd op 20/09/2019 04:47:28 door Daniel van Seggelen
Kijk bij jou onder welke user Apache draait en gebruik die user.
kijk eens welke user apache draait:
Neem een simpele hello.php script en upload dat eens naar je public_html directory.
Dan:
Code (php)
1
ps aux | grep -v root | grep apache | cut -d\ -f1 | sort | uniq
Gewijzigd op 20/09/2019 10:17:21 door Bart V B
- de structuur van de bestandenboom, en of dat wel de goede insteek is
- wat deze nu eindelijk hoopt te bereiken met het sleuren en pleuren van al deze bestanden, laat staan waarom dat nodig zou zijn
Laten we het dus eerst eens hebben over het te bereiken doel of het gewenste gedrag van de applicatie, vervolgens hoe je komt tot een aanpak (+ motivatie) en tot slot voor wat voor eventuele problemen dit zorgt. En dan kunnen we doelgericht(er) gaan zoeken naar oplossingen.
Maar als onderweg blijkt dat het ofwel verstandiger is om je doel bij te stellen of van aanpak te veranderen, dan is er mogelijk helemaal geen sprake meer van de huidige problemen maar ontstaan er mogelijk andere.
Waar we nu mee bezig zijn is enkel symptoombestrijding, en daarmee ben je mogelijk aan het voortborduren op een slecht ontwerp. Het feit dat je al vastloopt op permissies geeft waarschijnlijk aan dat er veel meer aan de hand is.
Alles dan maar chmodden naar whatever grenst aan onnozelheid. Als je geen motivatie kunt geven voor de aanpak dan kun je beter teruggaan naar de tekentafel.