Apache prenant possession du file et du dossier

J'ai un site Django en cours d'exécution sur Ubuntu avec apache2 configuré avec mod_wsgi. Le media (dossier où les files téléchargés par l'user est ouvert) appartient à l'user ubuntu (avec l'access sudo) et le groupe de dossier media est www-data . Lorsque un nouveau dossier ou des files sont créés par Apache dans le dossier multimédia, certains process Python externes (p. Ex. subprocess.popen ) ne sont pas capables d'écrire dans ce dossier car ce dossier particulier appartient à www-data . Quelle est la solution de ce problème?

Ce que j'ai fait jusqu'ici ( django est l'user du système):

 sudo chown django:django -R mysite/media/ sudo chgrp -R www-data mysite/media/ sudo chmod -R g+w mysite/media/ 

ls -la résultat du dossier media (le dossier multimédia contient d'autres dossiers nommés avec des nombres entiers):

 drwxr-sr-x 2 www-data www-data 4096 Jun 8 02:20 11 drwxrwsr-x 6 django www-data 4096 Jun 7 18:15 10 drwxrwsr-x 5 django www-data 4096 Jun 7 18:13 9 drwxrwsr-x 5 django www-data 4096 Jun 7 18:11 8 

Comme vous pouvez le voir, le dossier nouvellement créé 11 est détenu par www-data non par l'user de django .

Quoi d'autre, j'ai essayé:

  • J'ai essayé d'append un user django au groupe www-data , mais rien ne les aide

Aidez-nous!

Mettre à jour

Malheureusement, la solution de Daniel ne fonctionne pas pour moi (obtenant encore IOError: [Errno 13] Permission denied ). Voici le résultat de la command getfacl mysite/site_media/ :

Avant

 # file: mysite/site_media/ # owner: django # group: www-data user::rwx group::rwx other::rx 

Après ( sudo setfacl -d -R -mg:www-data:rwx mysite/site_media/ )

 # file: mysite/site_media/ # owner: django # group: www-data user::rwx group::rwx other::rx default:user::rwx default:group::rwx default:group:www-data:rwx default:mask::rwx default:other::rx 

Vous pouvez utiliser les lists de contrôle d'access aux files, dans ce cas setfacl pour définir l'autorisation de file par défaut pour autoriser l'opération d'écriture pour le groupe. Si vous avez ajouté django au groupe www-data, puis avec la command suivante, l'user django aura une autorisation d'écriture sur tous les files appartenant à l'user de www-data.

  setfacl -d -R -mg:www-data:rwx mysite/media/ 

Remarque: vous devrez installer le package acl en utilisant apt-get install acl s'il n'est pas installé. Assurez-vous que ACL est activé pour votre partition – ce lien pourrait vous aider .

Le problème était la memory partagée. Cette réponse l'a aidé à le réparer.

En ajoutant none /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0 in /etc/fstab corrigé.

En regardant la sortie de votre directory, aux permissions du directory 11 pour être précis, j'ai constaté que Apache l'a créé avec des permissions lisibles en groupe, mais non groupables en groupe. Étant donné que vous pourriez vouloir que tous les users du groupe www-data aient des permissions d'écriture pour ces files / directorys, vous devez indiquer à apache pour créer des files / dirs avec des permissions d'écriture de groupe qui peuvent être exécutées en définissant l'option umask à WSGIDaemonProcess . Comme la documentation indique:

Habituellement, l'umask hérité serait 0022

vous n'obtiendrez toujours aucun set d'permissions écrites en groupe. Tout ce dont vous avez besoin dans ce cas est juste une valeur umask à 0002 et redémarrez Apache. Vous pouvez résoudre ce problème en exécutant WSGIDaemon en tant que user django en spécifiant le nom d'user pertinent.

Je ne comprends pas complètement votre description du problème, mais pensez que le problème est qu'il est défini comme un bit, c'est-à-dire le 's' in:

 drwxr-sr-x 

Jetez un oeil à: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories pour une description écrite mieux que je ne peux l'accorder. La page chmod man aussi. Essentiellement searchz l'information dans setgud. Il se comporte différemment sur les directorys que sur les files.

Essayez chmod gs sur le chmod gs multimédia, puis créez un sous-directory dans les médias et vérifiez si cela l'a empêché d'hériter les mauvais périphériques. Si vous avez juste besoin de renvoyer le bit setgid de tous les autres sous-menus.

Pour cette find est votre ami (il peut searchr sur les groupes de propriétaires et les perms)