• [^] # Re: Pour compléter...

    Posté par . En réponse à la dépêche État d'insécurité chez PHP. Évalué à -1.

    Pourquoi régler le umask correctement casserait-il quoi que ce soit sur un hébergement où les utilisateurs sont censés être totalement cloisonnés les uns des autres ?
    
    

    C'est pas bête comme sécurité en plus, par contre je sais pas pour itk/peruser mais suexec les fichiers non *.php sont lus par apache et il faut que les répertoires soient au minimum avec 0066 et les fichiers php peuvent avoir un umask 0077, je crois pas que des regles d'umask en fonction du fichier ça soit faisable, mais je ne connais pas bien.
    Pis je me méfie des applications PHP qui vérifient un peu n'importe comment si tel ou tel répertoire/fichier a les permissions d'écriture..
    Si quelqu'un sait pour un umask de fichiers/rep différents je suis preneur :)

    Il existe mod_chroot pour apache, et la fonctionnalité est aussi proposée par mod_security.
    Et comme mentionné plus bas, itk+chroot dans archlinux, mais l'auteur d'ITK est pas chaud du tout pour une telle fonctionnalité dans ITK, donc peu de chances que ça soit intégré à ITK.
    Je suis pas sûr que le chroot soit plus efficace niveau perfs que open_basedir quand même... (même si ok c'est le même niveau de sécurité).
    
    

    Sauf que mod_chroot est un chroot commun à tous les vhosts, comme mod_security je crois, ce qui est pas mal mais finalement moins bien que open_basedir car ne protège pas les utilisateurs les uns des autres, mais protège le serveur. Si j'ai bien compris le chroot d'itk, comme celui pour suexec, c'était afin de chrooter chaque virtualhost, peut-être au moment de l'appel à un CGI, surement lourd (plus qu'open_basedir j'imagine), mais ça doit être diablement sécurisé.
    Bref tout ça pour dire qu'open_basedir est pas si pourri, et c'est pour ça qu'il est encore là..