Droits d'accès à un fichier uploadé, Modifier le CHMOD à l'upload

[Anard]

Bonjour,

Sur mon site internet, je propose une section de petites annonces.
Les visiteurs peuvent envoyer diverses information sur leur accordéon et envoyer une photo de 500Ko.
Tout fonctionne très bien sauf un truc :
Si la personne supprime son annonce ou son compte ou modifie sa photo, un script PHP commence par faire un unlink pour supprimer l'ancienne photo du serveur.
Sauf que ça ne fonctionne pas. Systématiquement, toutes les photos envoyées sont enregistrées sur le serveur et je ne peux les supprimer qu'en accès FTP.

Je pense que c'est dû au fait que les photos uploadées ont un CHMOD 604.

Y a-t-il un moyen de modifier le CHMOD au moment de l'envoi de la photo ?
Sinon, je dois pouvoir le faire juste après l'envoi. Est-ce que, par exemple, la commande

Code

chmod('maphoto',0606);

peut fonctionner dans un dossier avec des droits non modifiés (705) ?
Quel serait la valeur la plus adaptée pour rester le plus sécurisé possible (je pense que dans le principe, 777 ne servirait à rien puisqu'une photo n'est pas exécutable...) ?

Merci à vous

[niap]

Bonjour,

Code

chmod("maphoto", 0644);

devrait faire l'affaire.
Lecture / écriture pour le propriétaire, lecture pour les autres.

Curieux unlink ne fonctionne pas.
Quelle version de PHP ? Tu n'aurais pas le safemode activé ?
Tu déplace le fichier chargé avec move_uploaded_file ?

[yponomeute]

Salut,

C'est curieux comme comportement effectivement. Si le fichier est créé par un script php le propriétaire du fichier est logiquement l'user sous lequel est exécuté le script, et donc selon toute logique c'est le même user qui va essayer de supprimer le fichier avec unlink. Les droits en "600" sont alors suffisants, 604 ou 606 ne devraient rien y changer.

[Anard]

Je ne vois pas de safe mode activé dans php.ini (PHP 5.6.6)
Oui, j'utilise bien move_uploaded_file pour créer ma photo uploadée.

J'ai du mal à comprendre exactement qui sont le propriétaire, le groupe, et les autres dans mes scripts PHP ?
Avec un chmod 606, ça fonctionne alors que ça ne fonctionnait pas avec 604. Donc je pense qu'en l'occurrence, PHP se considère comme faisant partie des "autres".

C'est curieux comme comportement effectivement. Si le fichier est créé par un script php le propriétaire du fichier est logiquement l'user sous lequel est exécuté le script, et donc selon toute logique c'est le même user qui va essayer de supprimer le fichier avec unlink. Les droits en "600" sont alors suffisants, 604 ou 606 ne devraient rien y changer.

Sauf si l'on s'est déconnecté et reconnecté entre temps peut-être ? Alors, l'identité n'est peut-être plus la même au moment du unlink.
Sur quoi se base-t-il pour déterminer l'identité ? Sur l'adresse IP ? Est-ce qu'il est possible, sur un fichier ou dossier donné, de lui demander qui en sont le propriétaire et le groupe ?

Ce message a été modifié par Anard - 3 Nov 2015, 17:27.

[Jaypee]

Il faut simplement utiliser la commande ls -l pour voir le nom du propriétaire et celui du groupe

Code

rw-r--r--     1 jaypee  staff          6 28 jui 16:18 sdrx_unique.txt
-rwxr-xr-x     1 jaypee  staff         82 20 nov  2010 sed.sh
-rw-r--r--     1 jaypee  staff       7048 15 nov  2013 setupbind.sh
drwxr-xr-x     6 jaypee  staff        204 20 jan  2009 share
-rw-r--r--     1 jaypee  staff         38 25 avr  2013 showt.sql
-rw-r--r--     1 jaypee  staff        323 21 mar  2013 solveRPN.hs
drwxr-xr-x     7 jaypee  staff        238 10 aoû  2013 target
-rw-r--r--     1 jaypee  staff       4475 15 aoû  2005 test.plist

Le propriétaire est jaypee, son group est staff
Si Jaypee veut partager un fichier en lecture avec le groupe un 644 rw-r--r-- suffit
Le partage en écriture s'obtient avec 664 rw-rw-r--
Les permissions du bout à droite, ce sont celles du reste du monde
Et il est curieux d'essayer de traiter le groupe plus strictement que le reste du monde avec un 604, mais ça peut se concevoir, si on "sert" les fichiers par internet, les permissions locales ne jouent plus. Seul le service décide, pour tout le monde, et tous les fichiers.

J-P

[Anard]

Et il est curieux d'essayer de traiter le groupe plus strictement que le reste du monde avec un 604, mais ça peut se concevoir, si on "sert" les fichiers par internet, les permissions locales ne jouent plus. Seul le service décide, pour tout le monde, et tous les fichiers.

C'est comme ça que mes fichiers sont créés au départ (604) si je ne touche à rien. Mais oui, c'est sur un site internet (j'ai bien posté dans "Les langages du web"), les fichiers sont créés après upload en PHP.
Je suis d'accord que dans le principe, c'est étrange, mais je ne vais pas m'amuser à modifier PHP, chaqu'un son taf.
Qu'est-ce que tu entends par “si on sert les fichiers par internet” ? Il n'y a en fait aucun propriétaire du fichier sur internet ?

Et donc sur internet, je ne peux pas envoyer de commande Terminal pour demander quelles sont les autorisations sur mon fichier...

Mais merci quand même ...

Ce message a été modifié par Anard - 4 Nov 2015, 10:05.

[yponomeute]

Au lieu de faire un chmod sur les fichier existants, tu peux tenter de modifier la valeur de umask avant la création de tes fichiers.
Dans ton cas pour obtenir des droits 0606 il faut mettre umask à 0070 avec l'instruction php suivante

Code

umask(0070);

Instruction à exécuter en début de script avant la création du fichier uplooadé sur le serveur.

http://php.net/manual/fr/function.umask.php

Edit : tu es visiblement hébergé sur du mutualisé, il n'est pas sûr que la fonction umask soit prise en compte dans ce type d'environnement.

Ce message a été modifié par yponomeute - 4 Nov 2015, 17:32.

[Jaypee]

Qu'est-ce que tu entends par “si on sert les fichiers par internet” ? Il n'y a en fait aucun propriétaire du fichier sur internet ?

... que dans un service web, la permission ou le propriétaire du fichier sur disque n'a d'importance que pour le serveur lui-même.

Par exemple, si le serveur est un serveur web Apache, il tourne probablement sous une identité telle que www ou apache, mais pour autant, cela n'interdit à quiconque d'accéder au fichier, ce n'est plus la permission du répertoire du disque qui le décide, mais les permisisons qu'Apache décide de donner au dossier 'servi' sur internet, si on peut voir la liste des fichiers ou pas, s'ils sont cliquables ou pas.

L'un des principes simples de sécurité est de ne pas donner en même temps le droit d'écriture et le droit d'éxécution, car sinon on autorise d'uploader un executable (peut-être nocif) puis de l'éxécuter.

Pour l'upload, on configure parfois des "Drop zone" comme une boîte à lettre où on poste une lettre: On peut ajouter une lettee à poster, mais one ne peut pas voir le contenu dedans.

J-P

[Anard]

J'avoue que je ne comprends pas tout, ces notions me dépassent un peu... en tout cas je comprends qu'il soit un peu absurde de donner plus d'auhorisations aux "autres" qu'au groupe, mais mon code 606 semble très bien fonctionner et je suis la logique du serveur puisque par défaut, il mettait 604...

Mais dans l'idée, ça, je comprends bien :

L'un des principes simples de sécurité est de ne pas donner en même temps le droit d'écriture et le droit d'éxécution, car sinon on autorise d'uploader un executable (peut-être nocif) puis de l'éxécuter.

J'utilise quelques fichiers créés et lus dynamiquement (fichiers texte indiquant la date de la dernière MAJ et quelques autres données ainsi que le SiteMap et les flux RSS, qui sont modifiés dynamiquement lors d'une modification sur le site, principalement pour la section petites annonces).
Pour le moment, j'avais mis un CHMOD 777 sur ces fichiers, pour ne pas être embêté (et ne pas me poser de questions à ce sujet), mais à priori, un 606 suffirait très bien :
Un fichier de données .txt ne peut à priori pas être exécuté et le SiteMap et les flux RSS non plus (ils sont lus ou modifés). Seuls les .php sont exécutés.

J'affirme tout ça sans trop savoir. Dites-moi si (ou) je me trompe, ça m'aidera pour la suite

@yponomeute : Merci mais en effet, je ne pense pas que j'aie accès à cette fonction en mutualisé. Et je cherchais plutôt à modifier le CHMOD au moment de l'enregistrement (dans la commande move_uploaded_file).
Si j'ai bien compris, umask ferait la même chose que chmod, en autant de lignes (une ), en étant moins claire (chmod, je comprends bien ce que ça veut dire) et en étant placée avant plutôt qu'après.
Si j'ai bien compris (encore une fois), en plus, umask agit sur l'ensemble du script alors que chmod n'agit que sur le fichier qu'on définit. Vues mes connaissances dans le domaine, il me parait plus sécure d'utiliser chmod pour les futures modifs effectuées sur le site...

En fait, je ne connaissais pas la fonction chmod() et je l'ai trouvée de moi-même dans la doc après avoir posté (quel talent ! ) En revanche, sur le bien fondé de mon choix du 606 pour les photos et surtout du 777 pour les autres fichiers modifiés dynamiquement, je doute beaucoup...

Ce message a été modifié par Anard - 4 Nov 2015, 22:56.

[niap]

L'un des principes simples de sécurité est de ne pas donner en même temps le droit d'écriture et le droit d'éxécution, car sinon on autorise d'uploader un executable (peut-être nocif) puis de l'éxécuter.

Tu pourrais développer ce que tu dis ?
Ca m'intéresse de savoir comment on peux passer outre les vérifications d'upload (pour sécuriser mon CMS, pas pour aller faire le malin sur d'autres sites évidemment)

[yponomeute]

L'un des principes simples de sécurité est de ne pas donner en même temps le droit d'écriture et le droit d'éxécution, car sinon on autorise d'uploader un executable (peut-être nocif) puis de l'éxécuter.

Tu pourrais développer ce que tu dis ?
Ca m'intéresse de savoir comment on peux passer outre les vérifications d'upload (pour sécuriser mon CMS, pas pour aller faire le malin sur d'autres sites évidemment)

N'importe quel fichier peut être executé sur un système unix s'il a les droits requis.
Si je crée un script shell et que je nomme le fichier toto.jpg et que je lui donne les droits adéquats je peux l’exécuter.

Tu peux constater ça sur un Mac avec les commandes terminal suivantes par exemple

Code

touch toto.jpg
echo '#!/bin/bash' >> toto.jpg
echo 'echo "coucou"' >> toto.jpg
chmod +x toto.jpg
./toto.jpg

./toto.jpg va executer le fichier et la commande echo qui s'y trouve et va donc t'afficher coucou comme résultat.

Donc il est extrêmement simple d'uploader un fichier avec des commandes malignes incluses sur un site. Si ensuite on trouve un moyen d’exécuter ce fichier déposé sur le serveur c'est une porte d'entrée rêvée pour un pirate.

[niap]

Bien vue, les types MIME ne fonctionnent pas, le fichier est reconnu comme du JPG.
Si on vérifie le type du fichier avec exif_imagetype, l'image ne passe plus.