[PHP/FTP] Kan files niet meer aanpassen

[Struikrover]

Hallo,

Ik heb middels PHP een installatiescript geschreven. Het haalt een zipfile van een primaire locatie middels cURL, en pakt alle bestanden uit in een bovenliggende map. Zodoende wil ik een installatiescript / updatescript maken voor een applicatie, zodat deze makkelijk te deployen is. Uiteindelijk wil ik met de PHP GLIP library een manier maken om de GIT tags te verzenden van de (verder nutteloze) repository map en zo te checken op een update, en deze automatisch toe te passen op de applicatie.

Het probleem zit hem nu hierin:

Ik kan de files niet meer opslaan. die ik met het installatiebestand heb uitgepakt. Chmod staat bij files op 0644 en bij folders op 0755, en de user is 'ftp'. Het is een shared hosting dus alles wat ernaartoe kopieer heeft 'ftp' als user, en deze zelfde rechten. Toch kan ik de betreffende bestanden dus niet meer bewerken.

De foutmelding is algemeen en spreekt voor zich:

code:

Error transferring file 'hier/staat/het/pad/van/de/file'
---------------------------
Copying files to remote side failed.
parameters.ini: Permission denied

Heeft iemand een idee wat ik hieraan kan doen of hoe dit komt? Ik heb in het installatiebestand verder niet expliciet rechten gezet.

[ Voor 10% gewijzigd door Struikrover op 19-08-2012 19:18 ]

[Radiant]

Wat ik me kan voorstellen is dat je op een Windows server zit waar de FTP-server niet de echte permissions laat zien. Wat zegt je hoster erover?

[Struikrover]

Mijn hoster is Antagonist. Na een mailtje naar de helpdesk kom ik tot de volgende conclusie:

Het script en de zip worden met de user 'apache' uitgevoerd en uitgepakt. Daardoor komen GID en UID ook op 'apache' te staan in plaats van op mijn username, waardoor ik ze met de standaard rechtenset (644 en 755) niet kan bewerken.

Een oplossing zou zijn om de files 646 of 756 te maken, zodat 'other' ze ook kan schrijven.

Is dit ook de beste oplossing? Ik heb ook iets gelezen over het zetten van een sGID of sUID flag op een folder, zodat nieuwe mappen / bestanden de properties van die folder overerven bij het aanmaken, maar de info die ik hierover via Google kon vinden was niet erg duidelijk...

[Janoz]

Ik zou heel huiverig zijn om mijn bestanden die rechten te geven. Sowieso is het niet heel handig om je site zo in te richten dat hij zichzelf aan kan passen. Mocht je ooit ergens een foutje maken dan is het voor een hacker ook heel simpel om je site aan te passen.

Dergelijke update acties kun je beter extern draaien, dus niet op de site zelf.

[Struikrover]

Bedoel je dan om met FTP van buitenaf 1 voor 1 de bestanden te kopieren naar de doellocatie? Dat is toch veel minder efficient dan een zipfile overhevelen en deze uitpakken?

Ik lees bijvoorbeeld in de documentatie van Wordpress (toch geen kleine speler) dat men hier ook een install.php moet draaien om te installeren. En ik heb van diverse websites wat info over het updateproces van Wordpress gelezen. Hierbij is er ook een lokaal script dat bestanden van een remote afhaalt en ze in de goede locaties uitpakt. Er moet een manier zijn om dit goed af te handelen, en aangezien ik dit mooier vind dan met FTP commando's kloten om diverse redenen zou ik het graag ook op deze manier proberen.

Ik hoef inderdaad niet per se de genoemde rechten uit te delen, maar zou graag wel het "geheim" weten van de juiste manier.

Over het gevaar van de eigen website aanpassen: Ik ben voornemens om het installatiescript te verwijderen nadat het is uitgevoerd, en het enige script dat er dan nog overblijft is een updatescript dat alleen draait wanneer ik op een remote locatie aangeef dat het mag draaien. Op het moment dat een hacker deze remote locatie kan aanpassen in mijn config heb ik grotere zorgen dan het feit dat het updatescript misbruikt kan worden...

[ Voor 21% gewijzigd door Struikrover op 20-08-2012 10:04 ]

[KillerZero86]

Er zijn vele wegen naar Rome, maar zoals eerder verteld is het niet slim om de webapplication zichzelf te laten updaten. Wat mij vestqandiger lijkt is om een programma dat volledig los staat van je apache de verantwoordelijkheid voor de update te geven. Ik ben vooral thuis in de linux wereld en daar weet ik dat dit soort dingen vaak met pearl scripts gemaakt worden. Voor Windows zou ik het niet precies weten (BATCH kan lang niet zoveel als pearl of bash).

Ik denk dat dat de richting is waarin je moet gaan zoeken, zo kan de website zichzelf niet aanpassen, wat hackaanvallen minder schade aan laat richten.

[Janoz]

Struikrover schreef op maandag 20 augustus 2012 @ 10:00:
Bedoel je dan om met FTP van buitenaf 1 voor 1 de bestanden te kopieren naar de doellocatie? Dat is toch veel minder efficient dan een zipfile overhevelen en deze uitpakken?

Ja, het verschilt, maar ik vermoed dat je dit verschil nu enorm aan het overdrijven bent. Daarnaast, wanneer je 1 voor 1 je bestanden over kunt zetten kun je ook heel simpel eerst de index uploaden met daarin een "bezig met onderhoud", vervolgens alle andere bestanden, en tot slot je daadwerkelijke index.php. Je hebt zelfs ook nog de mogelijkheid om alle bestanden die niet conflicteren (nieuwe bestanden ipv geupdate bestanden) eerst te uploaden om tijd te besparen.

Kortom, minder efficient? Misschien. Gezipte programma code gaat sneller dan niet gezipte programma code, maar om hoeveel kb gaat het eigenlijk? De meeste daata zit toch echt in je plaatjes en daarvoor maakt het niet uit of je ze zipt of niet. Tot slot is de overhead van het ftp protocol mbt meerdere bestanden en een enkel bestand te verwaarlozen.

Ik lees bijvoorbeeld in de documentatie van Wordpress (toch geen kleine speler) dat men hier ook een install.php moet draaien om te installeren. En ik heb van diverse websites wat info over het updateproces van Wordpress gelezen. Hierbij is er ook een lokaal script dat bestanden van een remote afhaalt en ze in de goede locaties uitpakt. Er moet een manier zijn om dit goed af te handelen, en aangezien ik dit mooier vind dan met FTP commando's kloten om diverse redenen zou ik het graag ook op deze manier proberen.

De reden dat Wordpress het zo doet is omdat het voor de gebruikers makkelijker is. Gebruikers kunnen u gewoon vanuit hun adminconsole de update starten. Ze hoeven niet lokaal ook nog software te installeren of te draaien. Ze hebben de afweging gebruikers gemak vs veiligheid meer laten doorhangen naar gebruikersgemak.

Ik hoef inderdaad niet per se de genoemde rechten uit te delen, maar zou graag wel het "geheim" weten van de juiste manier.

Als je je site aan wilt laten passen door dezelfde gebruiker als de gebruiker die de site 'bekijkt' dan heb je geen andere mogelijkheid..

Over het gevaar van de eigen website aanpassen: Ik ben voornemens om het installatiescript te verwijderen nadat het is uitgevoerd, en het enige script dat er dan nog overblijft is een updatescript dat alleen draait wanneer ik op een remote locatie aangeef dat het mag draaien. Op het moment dat een hacker deze remote locatie kan aanpassen in mijn config heb ik grotere zorgen dan het feit dat het updatescript misbruikt kan worden...

Het gevaar zit niet alleen in het installatiescript. Het gevaar zit hem voornamelijk in het feit dat de bestanden en directories beschrijfbaar zijn voor iedereen. Er hoeft maar een keer een mogelijkheid te zijn voor code injectie en een hacker kan alle code aanpassen en/of een volledige eigen site neerzetten. En dan kun je nog wel vertrouwen hebben in je eigen code, je shared hosting kan ook een kleine fuckup doen (chroot jail niet op orde) icm een andere niet zo veilige site die op dezelfde server gehost wordt.

[Struikrover]

Even inline antwoorden

Janoz schreef op maandag 20 augustus 2012 @ 10:33:
Ja, het verschilt, maar ik vermoed dat je dit verschil nu enorm aan het overdrijven bent. Daarnaast, wanneer je 1 voor 1 je bestanden over kunt zetten kun je ook heel simpel eerst de index uploaden met daarin een "bezig met onderhoud", vervolgens alle andere bestanden, en tot slot je daadwerkelijke index.php. Je hebt zelfs ook nog de mogelijkheid om alle bestanden die niet conflicteren (nieuwe bestanden ipv geupdate bestanden) eerst te uploaden om tijd te besparen.

Kortom, minder efficient? Misschien. Gezipte programma code gaat sneller dan niet gezipte programma code, maar om hoeveel kb gaat het eigenlijk? De meeste daata zit toch echt in je plaatjes en daarvoor maakt het niet uit of je ze zipt of niet. Tot slot is de overhead van het ftp protocol mbt meerdere bestanden en een enkel bestand te verwaarlozen.

Oke, dat snap ik. Het gaat echter om een complete symfony2 installatie, zo'n 100 MB in 11.000 files dus. Ja, ik weet dat het niet ontworpen is om op een shared hosting neer te zetten. Toch wil ik dat graag proberen.
11000 files is een hele hoop om met FTP over te zetten denk ik. Wanneer ik zelf vanuit winSCP aan het kopiëren ben duurt het gerust 20 minuten om te uploaden. Een zip downloaden duurt een minuut, uitpakken misschien nog een halve minuut. Een behoorlijke tijdwinst, al is dat natuurlijk slechts de installatie en zal het updaten verwaarloosbaar zijn. Daarvoor is FTP vanuit de remote kant een goede optie.

Janoz schreef op maandag 20 augustus 2012 @ 10:33:
De reden dat Wordpress het zo doet is omdat het voor de gebruikers makkelijker is. Gebruikers kunnen u gewoon vanuit hun adminconsole de update starten. Ze hoeven niet lokaal ook nog software te installeren of te draaien. Ze hebben de afweging gebruikers gemak vs veiligheid meer laten doorhangen naar gebruikersgemak.

Janoz schreef op maandag 20 augustus 2012 @ 10:33:
Als je je site aan wilt laten passen door dezelfde gebruiker als de gebruiker die de site 'bekijkt' dan heb je geen andere mogelijkheid..

Dat is duidelijk. Ik wil eenzelfde functionaliteit bieden: de eindgebruiker van het pakket moet de applicatie zelf kunnen updaten. Installeren is niet per se nodig. Zelf updaten betekent dus automatisch dat de linux user die de website op mijn shared hosting 'bekijkt' (apache in dit geval) het updatescript zal moeten uitvoeren.

Janoz schreef op maandag 20 augustus 2012 @ 10:33:
Het gevaar zit niet alleen in het installatiescript. Het gevaar zit hem voornamelijk in het feit dat de bestanden en directories beschrijfbaar zijn voor iedereen. Er hoeft maar een keer een mogelijkheid te zijn voor code injectie en een hacker kan alle code aanpassen en/of een volledige eigen site neerzetten.

Bedankt voor je uitleg. Het hele rechtenverhaal is er duidelijker door geworden.

Even in een notendop een samenvatting voor mezelf (en mensen die meelezen ):

Er zijn twee users: debxxxxx (Antagonist hosting) en apache. Wanneer ik via FTP inlog en bestanden upload doe ik dat met mijn eigen user debxxxxx. Wanneer ik een PHP script bestanden laat plaatsen doe ik dat met de user apache.

Het voordeel van deze scheiding is dat scripts die met apache worden uitgevoerd, de bestanden die ik met debxxxxx heb geplaats niet mogen wijzigen, door de default rechtenset (644 en 755) die er wordt geset. Andersom kan ik met debxxxxx bestanden die met apache zijn geplaatst niet verwijderen of aanpassen.

Dit zorgt ervoor dat iemand die met een injectie toegang krijgt tot mijn script en eigen code kan uitvoeren de door mij geplaatste bestanden niet kan aanpassen of verwijderen. Om deze veiligheid te behouden zal ik alleen met debxxxxx bestanden moeten uploaden / uitpakken / whatever.


Conclusie: trade-off?
Wat nu, als ik op de een of andere manier een updatescript zou maken dat bestanden overschrijft, waarna ze voor beide users toegankelijk zijn (kan dit?). Dat houdt in dat, mocht iemand onverhoopt scripts kunnen uitvoeren, hij of zij alleen de update bestanden kan aanpassen of verwijderen. Deze schade zou beperkt blijven omdat de bestanden makkelijk hersteld kunnen worden.

[Struikrover]

Als aanvulling op bovenstaand bericht:

De trade-off gaat natuurlijk niet lukken, omdat ik de folder al schrijfbaar voor 'other' moet maken om er uberhaupt naartoe te kunnen overschrijven.

Het beste is dus inderdaad om extern een script op te starten. Dit kan vanaf de remote host, en hierbij is het handig om de installatie van tevoren handmatig te kopiëren. Het updatescript zal vervolgens steeds maar een aantal bestanden te hoeven plaatsen via FTP.

[Barryvdh]

Maar als je later toch met Git wil werken, kan je dan niet een clone maken van de Symony repo, of heb je dan dezelfde problemen?

[Struikrover]

Bij mijn eigen ontwikkeling werk ik natuurlijk al met Git. Op de shared hosting heb ik alleen geen SSH toegang dus geen terminal om git mee uit te voeren. Om de bestanden toch te kunnen updaten moet ik dus een manier bedenken om dit te doen aan de hand van de info uit de git repository, maar zonder git direct te gebruiken.

Op de remote host waar ik op ontwikkel maak ik nieuwe tags en zet ik bestanden klaar om te updaten. Die moet ik dan naar de shared host zien te krijgen.

[Barryvdh]

Host zoeken die wel SSH ondersteund?

[Struikrover]

De klant zelf is net overgestapt naar Antagonist (klein bedrijfje) en ikzelf heb dus wel iets met SSH, dus dat is niet echt een oplossing . Ik wil mensen ook niet graag per se moeten verplichten om een duur pakket met SSH te kopen als ze door mij geholpen willen worden.