3 votes

WSGIDaemonProcess : spécifier un utilisateur

J'ai un compte utilisateur configuré pour cette application web Python que je déploie avec mod_wsgi. C'est un compte super non privilégié, qui ne peut lire que dans le répertoire d'application et écrire dans un ensemble séparé de répertoires temporaires que personne d'autre ne peut consulter. J'utilise la ligne de configuration suivante :

WSGIDaemonProcess xlsxf_daemon user=xlsxf group=xlsxf

C'est assez simple. Malheureusement, nous avons ensuite ceci dans la documentation à propos de l'option user option :

Notez que cette option est ignorée si Apache n'a pas été lancé en tant qu'utilisateur root, auquel cas, quels que soient les paramètres, les processus démons seront exécutés sous l'utilisateur sous lequel Apache a été lancé.

Puisque j'exécute ceci dans une installation Ubuntu par défaut sur Linode, Apache démarre en tant que www-data et l'application Python que j'ai confirmée est condamnée à fonctionner également en tant que www-data . Pourquoi la limitation ci-dessus ? J'ai beaucoup d'applications ruby/passenger qui se démonisent en tant qu'autres utilisateurs sans problème.

modifier : ok, donc Apache ne commencer comme le www-data mais je vois toujours que la webapp Python s'exécute en tant que www-data malgré la ligne de configuration ci-dessus. /edit

Sinon, est-ce que je suis trop paranoïaque ? J'ai plusieurs projets différents en cours d'exécution sur ce serveur, et je voudrais qu'ils soient tous exécutés en tant qu'utilisateurs distincts, "juste au cas où", mais n'hésitez pas à me dire que je devrais simplement céder et déplacer les permissions à www-data .

edit2 : Comme demandé, voici tous les processus apache en cours d'exécution :

root     18798  0.0  1.9  16156  9880 ?        Ss   Jul26   0:03 /usr/sbin/apache2 -k start
www-data 19344  0.0  1.0  15208  5264 ?        S    Jul26   0:00 /usr/sbin/apache2 -k start
xlsxf    19361  0.0  1.2 155244  6620 ?        Sl   Jul26   0:02 /usr/sbin/apache2 -k start
www-data 19379  0.0  3.2 245436 16420 ?        Sl   Jul26   0:01 /usr/sbin/apache2 -k start
www-data 19380  0.0  3.2 243536 16496 ?        Sl   Jul26   0:01 /usr/sbin/apache2 -k start

3voto

Jason Points 8799

Vous le lisez mal. Apache démarre en tant que 'root' et le processus parent d'Apache reste en tant que 'root', seul le processus enfant du serveur Apache est exécuté en tant que 'www-data'. Les processus du démon mod_wsgi sont issus du processus parent 'root' et seront donc toujours capables de changer d'utilisateur.

Ce que le commentaire dit, c'est que si vous démarrez Apache à partir d'un compte totalement non privilégié, par exemple, comme vous le faites à partir d'une installation d'Apache dans votre répertoire personnel ou ailleurs, alors comme il ne démarre pas en tant que 'root', il ne peut pas changer l'identifiant utilisateur des processus du démon. Apache démarré à partir du système init scripts est toujours démarré en tant que 'root' et ne devrait pas poser de problème.

1voto

Alan Trulock Points 11

User and group fonctionne si votre ligne de configuration WSGIDaemonProcess est correcte. Je l'ai utilisé moi-même.

Voici mes lignes de configuration

WSGISocketPrefix /var/run/wsgi

<VirtualHost xx.xx.xx.xx:80>

WSGIDaemonProcess somedomain.com user=somedomain group=somedomain python-path=/home/somedomain/mysite:/home/somedomain/venv/myvenv/lib/python2.7/site-packages
...
...
...
</VirtualHost>

Cependant, vous ne souhaitez généralement pas le faire pour des raisons de sécurité. Si vous exécutez votre serveur web avec le même utilisateur qui a les droits d'écriture sur votre dossier web /home, cela constitue un risque pour la sécurité. Il est généralement préférable d'omettre ces droits et de laisser le serveur s'exécuter sous l'utilisateur apache par défaut. Assurez-vous simplement que apache appartient au groupe qui a les droits de lecture et d'exécution sur votre dossier web.

NOTE : Voyez comment j'ai le WSGISocketPrefix /var/run/wsgi en dehors de la section de l'hôte virtuel. Le démon WSGI ne fonctionnerait pas sans cela.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X