Utilisateurs Nobody Et Root

[fdm900]

Bonjour,

Je m'y perds un peu entre utilisateurs, groupes et les différences entre ce qui est défini via l'interface de gestion des synos et ce que l'on voit dans une session SSH ou telnet. Conséquence: ce n'est pas simple d'installer des applis web, ça ne marche pas à tous les coups, bien souvent dû à des problèmes de droits.

Voici ce que j'ai pu glaner sur les users nobody et root:

User webserver -> nobody

The user webserver is the one you get when enabling "web services".

The 'user' is running under user 'nobody' rights. Therefore, scripts don't have access to all files and directories. But, PHP is included, as well as MySQL access (if running). This is the perfect solution for user web sites and programs. Note that the rights of filereading or executing programs is further limited in de PHP.ini file by default.

System webserver -> root

The system webserver is for everything you have to do to administrate the diskstation.

The 'system' is running under root rights. Therefore, scripts do have access to all files and directories. Installing scripts that don't need those rights, might jeopardies the security of your system.CGI is enabled, but PHP is not included.

A lot of webapps out there need their group and owner to be set to nobody (chown -R nobody:nobody dirName).

This if because the servlet container running them (ie. Tomcat, JBoss) is the nobody user running the webapp.

Questions:

1/ Existe-t-il des règles pour appliquer chown et chmod dans les fichiers et sous dossiers de /volume1/web?

2/ Quand affecter nobody (Owner et/ou Group)? Que garder en root (Owner et/ou Group)?

3/ Quand je fais un listing des fichiers, je vois parfois apparaître 1080 mais c'est quel utilisateur? Root?

4/ Le compte Guest, a-t-il un rapport quelconque avec le user nobody?

5/ Comment s'assurer de la sécurité de son/ses sites web et des applis web installées? Existe-t-il une checklist?

A+

Flo

[cricx]

1924 root 352 S /usr/syno/apache/bin/httpd -DSSL -f /usr/syno/apache/

ce process tourne en tant que root car c'est l'instance qui permet l'admin du syno et donc nécessite des droits root. il écoute sur le port 5000

2533 nobody 1176 S /usr/syno/apache/bin/httpd -DSSL

ce process est lancé par l'utilisateur nobody, il gère les sites que tu as sur le syno et écoute le port .

les fichiers destinés aux applis web doivent appartenir à l'utilisateur nobody, ou au minimum pouvoir être lus par lui.

pour les comptes, vois dans /etc/passwd :

root:x:0:0:root:/root:/bin/ash

anonymous:x:21:21:Anonymous FTP User:/nonexist:/sbin/nologin

nobody:x:1023:1023:nobody:/home:/sbin/nologin

guest:x:1025:100:Guest:/nonexist:/bin/sh

[Diaoul]

Tu peux modifier le httpd-user.conf (je ne sais plus ou) pour changer l'utilisateur qui lance apache (actuellement nobody). Par contre tu ne peux pas faire un utilisateur par V-Host par exemple. Ça c'est Su-Exec et l'apache du Syno n'est pas compilé avec.

J'ai demandé a Synology d'implémenter SU-Exec dans leur apache ce qui permettrait que chaque utilisateur lance un apache sous son login. Il ne resterait plus à faire qu'un site dans le dossier home/www/ de l'utilisateur bidule et ce dernier serait exécuté avec ses droits.

Mais bon, Synology ne semble pas pressé d'après la réponse que j'ai reçu de leur part.

Tu devrais leur envoyer un mail pour le leur suggérer à nouveau, peut être cela fera-t-il avancer les choses.

Par ailleurs, SU-Exec est utilisé pour tous les hébergements mutualisés d'OVH.

[fdm900]

Merci cricx et Diaoul, je comprends un peu mieux le fonctionnement du syno et plus particulièrement d'apache.

J'ai bien vu aussi où se définissait l'utilisateur qui lance apache (/usr/syno/apache/conf/httpd.conf-user).

Avec la configuration par défaut (user nobody qui lance apache), j'ai essayé de suivre à la lettre le guide d'installation de Drupal 6.13 et suis tombé sur une erreur SQL! En tapant la ligne suivante, je n'ai plus eu d'erreur et suis arrivé à bout de l'installation.

chown -R nobody:nobody /volume1/web/drupal

(Drupal est dans son répertoire pour test.)

Est-ce que cela peut poser un problème quelconque? Problème de sécurité par exemple?

Intéressant l'emploi de su-exec, j'ai un bon contact chez Synology et vais le contacter en direct.

[Diaoul]

Franchement bizarre une erreur SQL. Un problème de permission pour un exec() aurait été plus compréhensible.

Su-exec serait le paradis ! Avec un peu plus de possibilités SSH (user-friendly j'entends) on aurait de quoi faire un vrai mutu sur nos Syno.

[MS_Totor]

oui

fais pression sur le collègue, c'est une option qui ravira bon nombre d'utilisateurs

[ikeke]

Au début, à l'époque du DS101+, exec() fonctionnait puis synology l'a retiré pour des questions de securités selon leurs dires. Depuis pas mal de monde demande le retour d'une telle fonctionnalité mais sans succès