Si je comprends bien votre question, votre problème commence par la structure du cadre d'autorisation/utilisateur Linux. Ainsi, l'utilisateur propriétaire du processus Apache est celui qui crée les répertoires et les fichiers lorsqu'il exécute votre script.
Si vous avez besoin d'une séparation des utilisateurs pour les scripts, par exemple :vous avez différents répertoires pour différents hôtes (virtuels) sur votre serveur et vous ne voulez pas que le script d'un hôte agisse sur les données d'un hôte différent sur le même serveur (apache), alors vous devriez utiliser 'mpm_itk_module' au lieu de l'apache 'mpm-prefork' plus courant.
En utilisant cela, vous pouvez aller définir l'utilisateur/groupe qu'Apache utilise lorsqu'il exécute des scripts et par ex. crée des répertoires juste par cette commande pour chaque entrée d'hôte virtuel dans le httpd.conf :
<IfModule mpm_itk_module>
AssignUserId USER GROUP
</IfModule>
Si vous voulez vraiment créer différents répertoires à partir d'UNE exécution de script, vous avez besoin que le processus Apache appartienne à root.root, puis le script doit définir les autorisations et les propriétaires pour chaque répertoire comme vous le souhaitez.
Mais ce n'est jamais une bonne idée d'exécuter même les meilleurs scripts sur un serveur Web en tant que root, car vous pourriez ne pas penser à tout risque.
La séparation utilisateur/droit par les vhosts semble être un moyen beaucoup plus économique à mon avis.
Un autre point - PHP uniquement - est suPHP -> http://www.suphp.org
MODIFIER :
Ok, j'ai jeté un coup d'œil à votre site et même si je ne parle pas espagnol, il semble que vous n'ayez qu'un seul site Web, agissant pour différents utilisateurs venant toujours à travers cette page Web. Alors, où est le besoin de séparation des utilisateurs sur les autorisations du système de fichiers Linux ? Vous pouvez tout restreindre par votre application sans avoir besoin d'utilisateurs de système de fichiers. Même si vous donnez par ex. accès ftp supplémentaire - limitez-le, par ex. avec proftpd, il a son propre mécanisme de chroot pour différents utilisateurs.
Vous ne devriez avoir à vous soucier des droits sur le système de fichiers que si vous ne pouvez pas contrôler qui exécute quoi. C'est un problème courant sur un hôte multidomaine que vous pouvez résoudre avec le mpm_itk_module que j'ai mentionné.
Peut-être devriez-vous décrire un peu plus votre situation ?
ÉDITION 2 :
Comme suggéré dans le commentaire, si vous utilisez UNIQUEMENT apache pour donner aux utilisateurs l'accès aux fichiers pour le téléchargement/la manipulation, placez simplement les fichiers en dehors (!) De l'arborescence documentroot d'apache et créez une base de données simple pour savoir quel fichier appartient à qui utilisateur :
user a | file parentdir/filename
Cela pourrait être un tableau simple et votre code php donne une liste à l'utilisateur à partir de la base de données quel fichier il est capable de voir/manipuler et votre code fait le travail comme prévu par l'action de l'utilisateur.
Tant que vous ne donnez pas à l'utilisateur l'accès aux fichiers par d'autres services (ftp, ssh, etc.), il n'est PAS nécessaire de travailler avec les droits d'utilisateur Linux. Veillez simplement à placer les fichiers en dehors du documentroot du serveur afin que seul votre code php ait accès aux fichiers par les droits de l'utilisateur apache de votre serveur.
ÉDITION 3 :
Haha, maintenant j'ai enfin eu votre problème après avoir lu un article similaire sur vous :(Comment un utilisateur Apache peut-il écrire des fichiers lorsqu'il a les autorisations nécessaires ?) Dans ce cas (avec des utilisateurs VRAIMENT anonymes sur votre page Web), vous n'avez AUCUNE chance de résoudre ce problème. Chaque visiteur est traité comme le même sans authentification. Et comme je l'ai supposé dans mon dernier EDIT et commenté dans le post similaire :pas besoin de gérer du tout les autorisations de fichiers Linux.
VOTRE SOLUTION ;) : Vous devez effectuer la manipulation de fichiers en une seule session avec des identifiants de session pendant que l'utilisateur visite votre page. Votre code doit donc gérer la relation entre le visiteur (l'identifiant de session) et le fichier qu'il a téléchargé avec cet identifiant de session. L'utilisation d'un identifiant de session valide tant que le visiteur est en ligne est la meilleure façon de procéder. Et encore - pas besoin d'autorisations de système de fichiers...;)
La deuxième méthode consiste à utiliser des utilisateurs authentifiés, comme suggéré précédemment :créez une table db avec des utilisateurs/mots de passe pour vous connecter à la page Web (pas au serveur) et une autre table contenant les relations utilisateur/fichier. Ensuite, après s'être connecté à la page Web, travaillez à nouveau avec des sessions pour permettre à l'utilisateur d'accéder/de manipuler des fichiers déjà téléchargés.
Je peux que vous exécutiez apache avec mod_php. Cela signifie donc que votre instance PHP fonctionne sous une instance apache et a apache USER et GROUP. Vous pouvez créer un dossier et changer le propriétaire de ce dossier, mais le propriétaire doit être un utilisateur de votre système (pas apache ou le même utilisateur virtuel).
Mais vous pouvez stocker dans chaque répertoire un fichier par exemple ".permissions" et mettre dans ce fichier le propriétaire virtuel. Ensuite, vous devez filtrer chaque tentative d'écriture (supprimer, renommer, etc.) dans ce répertoire et comparer votre utilisateur virtuel et l'utilisateur stocké dans le fichier .permitions.
Exemple de classe (pas complet mais c'est plus que suffisant pour comprendre l'idée) :
class UserDirs {
private $path='/home/vusers';
public function mkdir($user){
$d = $this->path.'/'.md5($user);
mkdir($d);
file_put_contents($d."/.owner",$user);
}
public function checkOwner($user, $dirname){
$f = $dirname."/.owner";
$virtual_owner = file_get_contents($f);
return $user === $virtual_owner;
}
}
$d = new UserDirs()
$d->mkdir("foo","bar");
echo $d->checkOwner("foo1","bar") === true ? "OK":"FAIL";
echo $d->checkOwner("foo","bar") === true ? "OK":"FAIL";
Vous pouvez encapsuler tout ce dont vous avez besoin dans cette classe pour travailler avec UserDirs et étendre la classe en fonction de vos besoins.
Vos utilisateurs n'ont pas de comptes système. Il n'est probablement pas possible de créer ces comptes non plus. Par conséquent, je vous recommande de gérer tout cela via l'interface utilisateur Web.
Continuez à créer vos répertoires tels que vous êtes. Les autorisations sont bonnes. Votre interface utilisateur doit cependant changer pour afficher uniquement le répertoire ou les fichiers de cet utilisateur. Je suppose que vous avez une base de données associée à cette page. Associez les noms d'utilisateur et le nom de répertoire généré aléatoirement à l'utilisateur. Si quelqu'un tente d'accéder au chemin direct et qu'il n'est PAS l'utilisateur associé à ce répertoire, renvoyez-le à l'écran de connexion.
Pour illustrer, j'ai créé un compte nommé test et a vraisemblablement reçu un répertoire unique. Si je me déconnecte, je ne devrais pas pouvoir visiter ce répertoire car votre code verrait cela
- Je ne suis pas connecté et n'ai donc pas accès à ce répertoire
Si je devais me connecter en tant que test2 et visitez le répertoire de test , votre code devrait voir cela
- Je ne suis pas le propriétaire du répertoire visité et je dois donc être redirigé le cas échéant.
Vous devez ajouter une fonction qui vérifie le répertoire que l'utilisateur visite et le compare au répertoire associé à l'utilisateur. S'ils correspondent, laissez-les continuer. S'ils ne correspondent pas, redirigez l'utilisateur.