PHP: Volgende kwestie: mkdir

B

BiG_G

Ik heb een fotoalbum volledig geschreven in php.
Op de webserver maakt ie een dir's aan, die krijgen echter als owner en group: apache apache
Ik wil dat dat wordt: pietje pietje
Hoe krijg ik dat voor elkaar?
 
Dat ga je alleen voor elkaar krijgen als je niet wilt dat er nog meer dirs aangemaakt worden.
Wil je het namelijk door php laten doen zul je Apache schrijfrechten moeten geven en zou het "pietje apache" moeten worden i.p.v. "pietje pietje".
 
Dat is het hem juist, omdat apache de rechten krijgt (heeft), is de owner per def. apache en de group ook.
Apache kan dus group en owner veranderen omdat apache de eigenaar is van die net aangemaakte dirs.
En ik wil dus dat dat eigenlijk gewoon meteen gebeurd, waarom zou dat niet kunnen?
 
Jawel, je begrijpt me verkeerd. Het kan wel werken, alleen niet met zowel owner als group van de user pietje. Apache zal de groups schrijfrechten moeten houoden omdat ie anders geen dirs meer kan aanmaken.

Het proggie of scriptje op zich zou wel pietje (om bij jou voorbeeld te blijven) als owner moeten kunnen krijgen. Zo word het dan "pietje apache", ik wilde alleen aangeven dat "pietje pietje" niet zou werken.

Het zou dus wel moeten lukken om "pietje apache" te kunnen maken alleen weet ik niet hoe dat met php moet. Misschien als ik straks of morgen wat meer tijd heb, dat ik eens ga zoeken hoe ze dat bij de Advance Transfer Manager (atmfree.fr) hebben opgelost. Een soort upload/download proggie wat net als deze forumsoftware (bij de attachments) eenzelfde principe nodig heeft.
 
Ja, maar dat snap ik dus idd niet;
Als de dir van pietje pietje is, maar een chmod naar 777 heeft gekregen, heeft apache nog steeds schrijfrechten... (toch?)

Dus zou pietje pietje gewoon moeten kunnen.

Het probleem opzich is opgelost door een andere toepassing te nemen, maar desondanks wil ik dit wel graag weten.

Volgens mij moet het gewoon kunnen.
 
Rechten moet je anders regelen. Zoals files in een eigen dir zetten die niet direct vanaf internet te benaderen is, en via een db regelen dat de betreffende items wel op te vragen zijn. Je webserver draait onder een eigen user en group. Je gebruikers loggen wel in, maar daarmee wordt je server niet door die user opnieuw gestart. Met shellscripting vanuit php kan je wel eea regelen, maar dat moet je niet willen ivm security.

Maar in een dir waarin door iedereen geschreven mag worden, kan idd iedereen schrijven. Maar wat moet je daar nou mee? Een puinzooi bouwen? Euh... laat maar. Ik wil het niet weten. :)
 
Ja, maar dat snap ik dus idd niet;
Als de dir van pietje pietje is, maar een chmod naar 777 heeft gekregen, heeft apache nog steeds schrijfrechten... (toch?)
Theoretisch gesproken wel omdat "world" dan ook schrijfrechten heeft.
Alleen vermoed ik dat het dan niet lukt omdat Apache niet "world" is maar een bestaande group en derhalve niet van de world rechten gebruik kan maken maar groepsrechten toegang moet hebben, derhalve ook "pietje apache".

Doch zoals gezegd, dat is mijn vermoeden, zeker weten doe ik het niet, misschien dat Kerstkonijn als Unixbeheerder daar meer zekerheid of duidelijkheid in kan verschaffen want die vraag maakt mij nu eigenlijk ook wel nieuwsgierig.
 
De laatste 7 betekent rwx rechten voor others. En dat is iedereen. Maar mogelijk dat in de config van apache zo is ingesteld dat apache daar helemaal niet kan komen. Dan kan ie, qua rechten, daar nog steeds schrijven, maar weet ie die locatie never-nooit-niet te bereiken.
 
En dus snap je meteen mijn vraag.

Ik ga weer lekker verder in m'n boek... Ben op de helft, heb verder geen tijd gehad met die paasdrukte op dat meubelboulevard...

Morgen weer verder, volgende week uit?
 
Ja, en dan begint het pas...

... de praktijk. Dan kom je er achter wat je niet weet.
 
De laatste 7 betekent rwx rechten voor others.
Ik kan er in httpd.conf niet zo vlug een instelling voor vinden.
Maar daar zeg je precies wat ik ook dacht. Rechten voor "others". Apache is geen "others" maar een "local user".

We zullen ermee moeten leren leven denk ik. Maar wel interessante materie.
 
Ik snap nu even niet wat je bedoelt met 'instelling voor httpd.conf'. Nu zal ik de plank wel misslaan, maar door dat PHP de actie doet, heeft httpd er toch nietzoveel mee te maken?
In je .php zet je de mkdir en de chmod etc... Dus lijkt het me logisch dat dat niet in httpd.conf te vinden is.

En in HEEL unix wereld betekend 'others' "iedereen"! Dus dan ook Apache of wie dan ook.
Daarom verbaas ik me destemeer dat apache, terwijl chmod 777, toch somige dingen niet zou kunnen.

Nu achteraf denk ik zelfs dat het niet aan apache ligt, maar aan de manier waarom het betreffende album in elkaar is ge-php-ed (kan je spreken van programeren? Tis geen programeer taal, maar een scriptingtaal (wordt ik misschien toch ooit nog eens een scriptkiddie :biggrin:))

Just thinking hardop.


G
 
Dat kwam door een uitspraak van KK:
Maar mogelijk dat in de config van apache zo is ingesteld dat apache daar helemaal niet kan komen.
Vandaar dat ik in de httpd.conf (config van apache) ging kijken of er iets in te stellen was wat dit betreft.
PHP doet de actie wel, maar apache bemoeit zich er toch mee. Kijk bijv. maar eens met een uploadscript (zoals phpatmfree). Dat is ook php, doch als je in de php.ini tot 8mb mag uploaden, maar in de apache.conf op 2mb gelimiteerd is krijg je niet meer geupload (via web) dan 2 mb.
Lijkt me ergens ook wel logisch, zonder webserversoftware geen webpagina's dus dan heb je ook niets aan php.

En in HEEL unix wereld betekend 'others' "iedereen"!
Tja wat is het nu? Jij zegt "iedereen", KK zegt "others" oftewel "anderen" en nog ergens in een linux stukje (en mandrake zelf zegt dit ook) lees ik dat het "world" oftewel wereld is.
Wat dat betreft heb je dus wel gelijk. Alleen vroeg ik me af of ze met "world" het dan niet over externe connecties hebben. Maar dat zal dan wel niet.

Als het echt iedereen is, dan zou dus bij een rwx op die laatste groep apache er ook bij moeten kunnen en dan blijft onze vraag staan waarom het dan niet werkt.
Misschien is het dan inderdaad de manier waarop het php ding in elkaar gezet is geworden.

Het enige wat ik weet is dat bijv. bij vbulletin apache schrijfrechten moet hebben op de dir voor de attachments en dat ook dit niet werkt door iedereen maar schrijfrechten te geven. Maar ook dat kan dan weer liggen aan de manier waarop het phpscript geschreven is.
Dus wie weet is je gedachtengang zo gek nog niet.:)
 
Anderen, wereld, iedereen: Komt allemaal op het zelfde neer. De eerste twee zorgen dat de eigenaar en de groep wel of geen toegang heeft, de laatste zorgt voor al het andere. Dus iedereen, de hele wereld, alle anderen.
Dus in het geval externe connecties: Jij kan makkelijk een externe connectie maken en toch de eigenaar van het bestand zijn.
(denk even via internet, ftp oid)

Hoe langer ik er over nadenk, denk ik toch dat het een vaag programmeer probleem is.
 



Oliebollen Hosting Fun Oliebollen

Advertenties

Terug
Bovenaan Onderaan