1. Tijs Drukker Member

    Php script Permission denied

    Topic geplaatst op: 18-07-2012 om 18:43

    Hallo allemaal,
    Ik ben bezig met een script om een vanuit een formulier bestanden aan te maken in een bepaald folder die gegeven is. Alleen krijg ik elke keer deze error: failed to open stream: Permission denied in *path naar bestand*. Ik heb nu mijn bestand nu op Permission 777 ingesteld maar het de error verdwijnt niet. Op internet heb ik gelezen dat je iets in je php.ini moet aanpassen maar daar heb ik natuurlijk geen toegang voor. Het script is gebasseerd op dit: http://php.net/manual/en/wrappers.php.php. Zelfs simpelse script werkt niet. Wat zou ik moeten doen waardoor ik die error weg krijg en mijn script gaat werken?

    Mvg T.Drukker

  2. zeromechanic Member
    Reactie geplaatst op: 18-07-2012 om 19:53

    Je hebt dus het script bestand op 777 gezet??
    dat werkt dus niet.

    je geeft aan dat er bestanden in een bepaalde folder gemaakt moeten worden.
    dan zul je die mappen op 777 moeten zetten.

    bv
    mainmap -> 777
    mainmap=>map1 -> 777
    mainmap=>map2 -> 777

    maar als het goed is, als je mainmap op 777 zet, en de submappen laat aanmaken door php, hoeven die niet op 777 omdat apache dan eigenaar is.

    mss wel betere optie op suPHP in te schakelen, hoef je niks meer op 777 te zetten, wat overigens ook wel veiliger is.

    EN !!!!!!!!!!!!!!!!!
    wees paranoia met formulier inputs, vooral als bezoekers van je website dit kunnen invullen!!!!!!
    FILTER de (user)input !!!!!!
    anders kun je straks een bericht plaatsen dat je site gehacked is, of iets dergelijks.

    Vond u dit antwoord nuttig?

  3. Tijs Drukker Member
    Reactie geplaatst op: 19-07-2012 om 00:45

    Aha dank u wel, heb alle mapjes in de mainmap naar 777 gezet en nu werkt mijn script.

    Het script is bedoeld voor een admin systeem voor mijn website dus je moet eerst inloggen met een md5 gecodeerd wachtwoord. Dus er kan denk niet zomaar iemand zo'n bericht plaatsen.
    Zijn er nog verdere beveiligings toepassingen essensieel voor het inloggen?

    Mvg T.Drukker

    Vond u dit antwoord nuttig?

  4. zeromechanic Member
    Reactie geplaatst op: 20-07-2012 om 20:59

    Beter sha1 te gebruiken als hash.
    (sha256 mss ook wel te gebruiken, krijg je een langere string)
    sla NOOIT op in sessies of cookies -> gebruik database
    geef wachtwoorden een salt mee
    gebruik mysql_real_escape_string

    Vond u dit antwoord nuttig?

  5. Evert Jan Karman Member
    Reactie geplaatst op: 20-08-2012 om 23:50

    Die map op 777 zetten kon ik niet in DirectAdmin maar wel in mijn eigen ftp-programma WinSCP. Kan dit kloppen?

    Vond u dit antwoord nuttig?

  6. Danny Simons Member
    Reactie geplaatst op: 21-08-2012 om 21:06

    @Tijs
    Zoals zeromechanic al een beetje aangaf: zet je mappen nooit op 777! Hiermee zet je namelijk alles voor de buitenwereld open en een beetje handig persoon kan hiermee foute scripts installeren en deze aanroepen. Gevolg is dan doorgaans dat er dingen gebeuren die niet de bedoeling zijn.
    Als je de mogelijkheid voor suPHP hebt zou ik die inderdaad inschakelen. Meestal zijn rechten 660 dan al voldoende. Zonder suPHP kom je met 664 trouwens ook een heel eind, zeker als je de map(pen) allemaal als eigenaar apache meegeeft.

    Ik weet niet hoe je script in elkaar steekt, maar als het met een lagere permissie dan 777 niet werkt kun je het wellicht met een ftp-script proberen; dit is altijd veiliger dan alles open zetten.

    Suc6!
    Danny.

    Vond u dit antwoord nuttig?

  7. zeromechanic Member
    Reactie geplaatst op: 22-08-2012 om 16:35

    @danny

    user apache is vaak het probleem met de rechten.
    met suPHP draait alles onder je eigen naam, en niks onder apache !!
    miss dat je wel eigenaar moet aanpassen middels DA, dus apache => eigennaam(daaccount naam).

    onder suPHP geeft alles boven 644 voor bestanden en 755 voor mappen een 500 server error!!
    tevens kun je onde suPHP ook geen PHP flags meegeven in htaccess, dit resulteert ook in 500 server error. Je hebt dan een .user.ini nodig.

    Vond u dit antwoord nuttig?

  8. Danny Simons Member
    Reactie geplaatst op: 22-08-2012 om 23:06

    @zeromechanic

    idd geeft suPHP fouten boven 644; was even in de war, vandaar dat ik 660 meldde. Zelf gebruik ik namelijk al enige jaren FreeBSD en dan heb je niets aan suPHP.
    Toen ik nog met CentOS draaide gebruikte ik wel suPHP.

    Wat ik meldde over gebruiker apache sloeg overigens op de situatie wanneer je suPHP niet kunt of wilt installeren.

    Maar hoe dan ook: 777 is vrijwel altijd uit den boze!
    :-)

    Vond u dit antwoord nuttig?