[PHP] rechten geuploade file

[P.O. Box]

Ik heb hier nog nooit problemen mee gehad, maar nu gaat het ineens mis bij een nieuwe site die ik aan het maken ben, en ik heb geen idee waarom...

ik maak in de code een directory aan als deze nog niet bestaat en ik zet in deze directory een afbeelding neer... gaat allemaal prima...

alleen als ik nu het bestand of de map via FileZilla wil verwijderen, dan heb ik daar geen rechten op...

ik heb qua map het volgende geprobeerd:

code:

1. mkdir($map);
2. mkdir($map, 0777);
3. mkdir($map, 0777, true);

en
4. 
mkdir($map);
chmod($map, 0777);

en een aantal combinaties van bovenstaande...
als ik dat gedaan heb en ik bekijk in FileZilla de hoofdmap, dan zie ik dat de map de volgende rechten heeft: fle (0755)... dat is dus al geen 0777
ga ik via WS_FTP kijken dan zie ik het volgende voor de map: drwxr-xr-x
lijkt verdomd veel op 0755, en dus geen 0777
als ik op manier 1 de map aanmaak, dan is de map 0644... als ik manier 1 gebruik en daarna chmod(0777) dan is de map 0755... mijn conclusie daaruit is dat de php-functie chmod door mijn provider iig wel ondersteund wordt, maar dat er toch iets mis gaat...

bij het bestand is het nog iets vreemder...
als ik daar in filezilla kijk (nadat ik in de code chmod(0777) op het bestand heb gedaan, dan staat er in filezilla: adfr (0777)... .kijk ik via WS_FTP, dan staat er: -rwxrwxrwx. Dus ik denk dan: mooi, die kan ik via FileZilla / WS_FTP wel verwijderen.... euhhuh *.... ik kan het bestand dus niet verwijderen...
opvallend is, als ik met FileZilla zelf handmatig een bestand upload, dan heeft dat bestand de volgende rechten: adfrw (0777)... misschien dat daar het verschil nog in zit?

mijn vraag is vrij simpel: is dit een setting die mijn provider ineens heeft doorgevoerd (eerder nooit problemen gehad, en gebruik dezelfde login) ? of zie ik iets gruwelijk over het hoofd ? of ... of... of...


* denk hier het geluidje van 5 tegen 5...

[NMe]

Ik denk inderdaad dat je host iets veranderd heeft waardoor de Apache-gebruiker blijkbaar geen schrijfrechten kan toekennen aan bestanden. Wat dat dan is durf ik niet te zeggen, ben dit nog nooit tegengekomen. Heb je ze al eens gemaild?

[ReenL]

Sowieso is het raar om mappen te chmodden naar 777, wil je dat alle andere gebruikers op je shared host er ook bij kunnen ofzo? Wat is het doel?

Waarom verwijder je de mappen niet met php, die heeft ze immers ook aangemaakt.

[P.O. Box]

NMe schreef op vrijdag 04 februari 2011 @ 22:58:
Ik denk inderdaad dat je host iets veranderd heeft waardoor de Apache-gebruiker blijkbaar geen schrijfrechten kan toekennen aan bestanden. Wat dat dan is durf ik niet te zeggen, ben dit nog nooit tegengekomen. Heb je ze al eens gemaild?

nee nog niet, zit er sinds begin van de avond mee te kloten, en verwachtte op vrijdagavond eerder antwoord op GoT dan via de helpdesk

ReenL schreef op vrijdag 04 februari 2011 @ 23:03:
Sowieso is het raar om mappen te chmodden naar 777, wil je dat alle andere gebruikers op je shared host er ook bij kunnen ofzo? Wat is het doel?

het doel was in dit geval wanhoop

Waarom verwijder je de mappen niet met php, die heeft ze immers ook aangemaakt.

ja, dat gaat uiteindelijk ook wel gebeuren, maar ik ben nog in de ontwikkelfase... dan probeer je wel eens wat wat niet helemaal goed gaat... en dan wil ik gewoon een hele rits bestanden in 1 x kunnen verwijderne, omdat ik nog niet aan het verwijder scriptje ben toegekomen

[borft]

als je een goeie hosting provider hebt, dan draait het webserver proces van jouw domein met dezelfde user als jouw user. maw, je kunt je bestanden dan 640 en je dirs 750 maken.

In het geval van jouw hoster is er vast een verplicht umask ingesteld dat voorkomt dat iedereen zomaar bij jouw bestanden kan.

[ReenL]

Bij deze:

PHP:

<?php
function recursive_unlink($path) {
    $path = rtrim($path, '/');
    if ( !file_exists($path) ) {
        return false;
    }
    if ( is_file($path) ) {
        return unlink($path);
    }
    $handle = opendir($path)
    if (!$handle) {
        return false;
    }

    $result = true;
    while (false !== ($file = readdir($handle))) {
        if ($file == '.' || $file == '..') {
            continue;
        }
        
        $fullPath = $path . '/' . $file;
        if ( is_dir($fullPath) ) {
            $result = removeDir($fullPath) && $result;
        } else {
            $result = unlink($fullPath) && $result;
        }
    }
    @closedir($handle);
    if ( rmdir($path) ) {
        return $result;
    }
    
    return false;
}

Net geschreven, fouten onder voorbehoud

[ Voor 0% gewijzigd door ReenL op 04-02-2011 23:26 . Reden: php ipv code-tag ]

[basdej]

heb je geen controle panel? (plesk? ) want met de bestandsbeheerder daar moet je de mappen wel kunnen verwijderen?

[borft]

of nog makkelijker:

PHP:

function recursive_delete($path){
return system('rm -r ' . escapshellearg($path));
}

[ Voor 3% gewijzigd door borft op 04-02-2011 23:29 ]

[ReenL]

@borft:
Werkt alleen niet op 90% van de shared hosts.

[P.O. Box]

basdej schreef op vrijdag 04 februari 2011 @ 23:28:
heb je geen controle panel? (plesk? ) want met de bestandsbeheerder daar moet je de mappen wel kunnen verwijderen?

ik ben even ingelogd op m'n control panel... en ik zie daar dat de eigenaar van de files die ik geupload heb via de browser staat op "apache", terwijl de files die ik via FileZilla heb geupload staan op "xxxxx". Als ik nu via het control panel de files (en map) "reset owner" doe, dan kan ik ze daarna wel verwijderen...

ik dacht dus slim te zijn en zette in mijn php-code: chown($map, 'xxxxx').... helaas gaf PHP de volgende error terug op de chown regel: "Operation not permitted"...

toch maar even mijn provider mailen dan... want lijkt er toch stevig op dat ze iets gewijzigd hebben...

kan de files iig verwijderen, of via control panel of via de hierboven genoemde script (helaas, de verkorte versie kan ik ook niet uitvoeren, geen exec-shell rechten)...

ik vind het vreemd iig... zal voor de volledigheid het antwoord van de provider hier nog wel laten weten...

[Bozozo]

Ligt het niet aan je CMS? Drupal wordt bijvoorbeeld ook owner van de files folder... zie hier.

[P.O. Box]

Bozozo schreef op zaterdag 05 februari 2011 @ 00:12:
Ligt het niet aan je CMS? Drupal wordt bijvoorbeeld ook owner van de files folder... zie hier.

ik gebruik geen CMS, dus dat kan het niet zijn...

[Anoniem: 146875]

Er zijn wat problemen met sommige distros. Een default Debian Lenny installatie geeft bijvoorbeeld problemen waardoor 0757 in werkelijkheid 0755 wordt. De volgende code werkt wel goed omdat de mkdir permissies gewijzigd worden door umask, die je eerst goed zet.

code:

$newmask = 0777;
$oldmask = umask(0);
$result = mkdir($directory, $newmask);
umask($oldmask);