Gestion des droits d'accès

Message 1, par Elzen

§ Posté le 13/01/2013 à 1h 50m 07

Unix et les systèmes qui en dérivent plus ou moins directement (dont les systèmes GNU/Linux comme Debian) sont naturellement multi-utilisateurs, c'est-à-dire que le système peut accueillir un grand nombre d'utilisateurs différents. Et c'est ce qu'il fait en pratique : même si vous êtes le seul utilisateur humain de la machine, le système comporte aussi plusieurs comptes dédiés à des tâches diverses.

Pour gérer tout ça, et empêcher que n'importe qui vienne mettre le bazar n'importe où, les fichiers sur le disque disposent de droits d'accès, qui déterminent ce que l'on peut leur faire.

Pour ceux qui ne sont pas familiers avec cette notion, commençons par expliciter un peu ça.


Les bases

Chaque fichier sur le disque est déterminé comme appartenant à un propriétaire, qui est un utilisateur du système, et à un groupe, qui est une sorte de rôle que peuvent prendre les utilisateurs (par défaut, un fichier appartient à l'utilisateur qui le crée, et au groupe principal de ce dernier (groupe qui porte le même nom que l'utilisateur)).


Basiquement, les trois accès possibles à un fichier sont les suivants :


Les droits d'accès d'un fichier sont les valeurs de ces trois accès pour le propriétaire du fichier, puis pour le groupe, puis pour les autres utilisateurs du système.

Par exemple, si un fichier appartient à l'utilisateur « machin » et au groupe « truc », et que ses droits d'accès sont « rwxr-xr-- »(1), cela signifie :


Dans les faits, les possibilités d'accès à un fichier dépendent des droits d'accès aux répertoires qu'ils contiennent. Par exemple, si vous avez le droit de lire un fichier, mais que vous n'avez pas le droit de naviguer dans le répertoire qui le contient, vous ne pourrez pas accéder au fichier.

À l'inverse, si vous n'avez pas le droit de modifier un fichier, mais que vous pouvez créer/supprimer des fichiers dans le répertoire qui le contient, rien ne vous empêche de supprimer le fichier en question et de le remplacer par un autre, ce qui revient à peu près au même que de le modifier (pas forcément tout-à-fait, mais je vous épargne les détails pointus).




Ce système est très intéressant, mais peut parfois s'avérer un peu problématique quand il s'agit de gérer les accès. Pour citer deux cas que je rencontre sur mon serveur :



Il faut donc faire en sorte de gérer les droits intelligemment, pour que chacun ait précisément les accès dont il a besoin. Il y a pour cela plusieurs possibilités, chacune ayant ses avantages et ses inconvénients.


Notez que si vous n'avez besoin que d'un accès en lecture, il est donné par défaut, donc vous n'avez aucune manipulation à effectuer.


La version intégrée et propre

C'est cette version que j'ai choisie sur mon serveur actuel.

Il s'agit simplement d'utiliser le fonctionnement de base du système, et principalement les accès du groupe. Par exemple, si je fais en sorte que tous les fichiers utilisés par le serveur web appartiennent au groupe « www-data », que tous les membres de ce groupe aient le droit en écriture sur ces fichiers, et que mon compte utilisateur appartient à ce groupe, je peux modifier ces fichiers sans problème.


Faire en sorte que mon compte utilisateur appartienne au bon groupe, c'est facile : il n'y a qu'une commande à lancer, et ça reste comme ça jusqu'à ce que je lance la commande inverse.

sudo adduser elzen www-data

Remplacez « elzen » par votre compte utilisateur à vous, et « www-data » par l'éventuel autre groupe concerné, bien sûr.


Faire en sorte que tous les fichiers du serveur web appartiennent au groupe www-data, c'est un poil plus complexe : comme on l'a vu, un fichier appartient par défaut au groupe principal de son propriétaire.

Les fichiers que l'utilisateur www-data, qui gère le site web, appartiennent donc bien au groupe www-data, mais les fichiers que je crée moi-même, eux, appartiennent par défaut au groupe « elzen ». Et je n'ai pas envie d'ajouter l'utilisateur www-data au groupe elzen.

Je peux lancer une commande (chown ou chgrp) pour changer le propriétaire et le groupe d'un fichier, mais ça n'affecte que les fichiers déjà présents, pas ceux que je n'ai pas encore créé.

Fort heureusement, il existe un mécanisme pour contourner ça : le « droit SGID ». Appliqué à un répertoire, ce droit particulier fait en sorte que tous les fichiers créés dans ce répertoire prennent, au lieu du groupe principal de leur propriétaire, le groupe auquel appartient le répertoire en question.

J'ai donc deux commandes à lancer :

sudo chown -R elzen:www-data /var/www
chmod -R g+s /var/www

La première affecte le répertoire /var/www (qui est le répertoire système censé contenir les fichiers du serveur web) à l'utilisateur elzen (donc, moi) et au groupe www-data. L'option « -R » rend la chose récursive, c'est-à-dire que tout le contenu de ce répertoire subira la même opération. La commande suivante ajoute (elle aussi récursivement) le droit SGID à ce répertoire.

Le gros avantage est que ce mécanisme est géré directement par le cœur du système, donc normalement, quel que soit l'outil utilisé, les fichiers créés dans /var/www (ou plus bas) appartiendront systématiquement à l'utilisateur qui les crée et au groupe www-data.


La difficulté, c'est de faire en sorte que les fichiers soient automatiquement modifiables par les membres de leur groupe. En effet, pour des raisons de sécurité, le « masque de droits » par défaut empêche de donner les droits d'écritures au groupe et aux autres utilisateurs.

Bien sûr, vous pouvez donner le droit d'accès en écriture à tous les fichiers déjà présents (chmod -R g+w /var/www), mais ça n'affectera pas les fichiers nouvellement créés.

Au niveau du CGI, vous pouvez sans doute régler ça facilement (dans PHP, la fonction umask fait ça très bien). Vous pourrez donc modifier les fichiers créés par le moteur du site ; mais il faudrait aussi l'accès inverse.

Dans un terminal, la commande umask vous permet de vérifier et de régler les droits qui seront donnés automatiquement à vos fichiers. Elle fonctionne avec trois chiffres en octal, comme les droits ci-dessus, mais à l'envers : le masque par défaut est « 0022 », ce qui représente (le premier zéro sert à indiquer que c'est de l'octal) « ----w--w- », qui sont les droits que l'on va retirer aux droits de base lors de la création d'un fichier.

En mettant ce masque par défaut à 0002 au lieu de 0022, on fait donc en sorte que les fichiers créés dans le shell courant conservent le droit d'écriture pour le groupe. Le truc est qu'il faut relancer la commande chaque fois qu'on ouvre un nouveau terminal, à moins de la mettre dans le fichier d'initialisation.

Pour les navigateurs de fichiers graphiques, comme Thunar ou Nautilus, il doit probablement exister un réglage adapté, mais comme je travaille sur mon serveur essentiellement en ligne de commande, je n'ai pas cherché comment ça se faisait.


Plus d'infos sur Wikipédia : SGID, umask.


La version fine et détaillée

Il existe une solution plus fine, extension de la gestion des droits natives, que j'utilisais sur mon ancien serveur : les ACL.


Cela permet de gérer, en plus des droits d'accès natifs, des permissions spécifiques pour chaque utilisateur (en gros, en plus de dire « les membres du groupe truc ont tels droits », vous dites directement « l'utilisateur machin a tel droit, l'utilisateur bidule a tel autre »).

Pour faire marcher ça, il faut ajouter l'option de montage « acl » à la partition sur laquelle se trouvent les fichiers concernés, donc si c'est sur une partition qu'il vaut mieux ne pas démonter en cours de route (la racine ou le home, par exemple), un redémarrage sera nécessaire.


Les ACL permettent donc une gestion détaillée, mais l'inconvénient est qu'il s'agit d'un truc en plus, qui n'est pas forcément bien géré par tous les outils de création de fichiers. L'une des raisons pour lesquelles j'ai abandonné cette pratique est que, sur mon ancien serveur, je devais régulièrement relancer le réglage des droits d'accès, à cause de fichiers qui n'avaient pas été correctement créés et ne reconnaissaient que les droits classiques.


La page de documentation sur laquelle je m'étais appuyé à l'époque pour mettre ça en place se trouve ici.


La version tarabiscotée

N'essayez pas ça chez vous, sauf si vous tenez à faire des bêtises. Cette solution est très probablement très mauvaise, mais elle me semble tellement amusante que je ne résiste pas à l'idée de vous en parler. Il s'agit de réaliser… des auto-montages réseaux locaux.


Il est en effet tout-à-fait possible de monter automatiquement des supports réseaux (sshfs, ftpfs, samba…) pour utiliser des ressources situées sur une autre machine comme si elles se trouvaient sur la machine active. Le principe est que vous connectez, par le réseau, un bout d'un disque dur distant dans l'arborescence locale, comme si vous montiez un support de stockage.


Or, votre machine peut à la fois être client et serveur, pour ces partages. Rien n'empêche donc, théoriquement, de monter un bout de votre disque dur local à un autre endroit de l'arborescence. Si vous montez, en tant qu'un utilisateur donné, un bout du disque, mais vous connectant en tant qu'un autre utilisateur, il devrait y avoir une sorte de changement automatique de propriétaire, qui permettrait à plusieurs utilisateurs d'avoir les mêmes accès sur certains répertoires.


Je tenterai ça, un jour, quand j'aurai le temps d'expérimenter des bizarreries.

Message 2, par Pylade

§ Posté le 13/01/2013 à 2h 42m 29

Tiens, quelques remarques…


Chez moi, le groupe principal des utilisateurs humain est « users », ils n’ont pas de groupe à leur nom.

Pour les droits en 754, j’écrirais plus 0754 pour bien préciser que c’est de l’octal.

Il y a une faute : « qu’une commande à lanc_er_ ».

Et pour le chmod récursif, j’ai l’impression que tu modifies aussi le SGID des fichiers réguliers, ce n’est pas le but recherché, non ?


Mais sinon, j’aime bien. ;)

Message 3, par grim7reaper

§ Posté le 13/01/2013 à 7h 16m 37

Citation (Elzen)

sudo adduser elzen www-data

La « vraie » commande c’est useradd (un binaire).

adduser ça peut être un script Perl (sous Debian et Ubuntu par exemple) plus interactif (mais qui fait appel à useradd en dessous), juste un lien symbolique sur useradd, ou peut-être ne pas exister sur certains systèmes.

Voilà, juste une petite précision ^^


Citation (Elzen)

Elle fonctionne avec trois chiffres binaires

Heu, c’est de l’octal, pas du binaire.

Ou alors j’ai mal compris ta phrase.

Message 4, par Elzen

§ Posté le 13/01/2013 à 13h 03m 16

Citation (Pylade)

Chez moi, le groupe principal des utilisateurs humain est « users », ils n’ont pas de groupe à leur nom.

Hmm. Et ils sont tous dans le même groupe ? Je n'suis pas forcément sûr que ce soit le mieux, niveau sécurité.

Mais je pense que ça vient d'un réglage spécifique de ton système, non ? Ceux qui ont un truc comme ça sont censés avoir les compétences pour adapter mes explications à leur cas, sinon pour s'en passer, je dirais.

Citation (Pylade)

Pour les droits en 754, j’écrirais plus 0754 pour bien préciser que c’est de l’octal.

Pas faux, mais j'ai tellement l'habitude de ne pas le mettre que je risque de continuer comme ça. Ç't'une convention purement informatique, d'ailleurs ; perso, j'ai appris à manipuler les bases en maths d'abord, donc j'aurais plutôt tendance à écrire (754)8.

(Tiens, j'avais oublié les indices et les exposants dans le parsage ElzML, je rajoute ça…)

Citation (Pylade)

Et pour le chmod récursif, j’ai l’impression que tu modifies aussi le SGID des fichiers réguliers, ce n’est pas le but recherché, non ?

Effectivement ; mais modifier le SGID des fichiers régulier n'a aucune influence pour deux raisons : d'abord, aucun n'a le droit x, et ensuite, il n'y a aucun ELF dans le lot (le SGID n'est pris en compte que pour les ELF, pas pour les scripts). Donc ça ne me choque pas particulièrement.

Ceci dit, il vaut effectivement mieux lancer cette commande dès le début, avant de commencer à mettre des fichiers particuliers dans ce répertoire, comme ça, tout est géré correctement (tout répertoire créé dans un répertoire avec SGID reçoit lui-même le SGID).

Citation (Pylade)

Mais sinon, j’aime bien. ;)

Merci ^^

Citation (grim7reaper)

Voilà, juste une petite précision ^^

Eh bah, merci de la précision, alors ^^

J'ai toujours appris à utiliser adduser, et je ne m'étais même pas posé la question de savoir s'il existait autre chose.

Citation (grim7reaper)

Heu, c’est de l’octal, pas du binaire.

On va mettre ça sur le compte de la fatigue ><

C'est corrigé, comme la faute de frappe signalée par Pylade.

Message 5, par Pylade

§ Posté le 14/01/2013 à 1h 08m 37

Citation (Elzen)

Mais je pense que ça vient d'un réglage spécifique de ton système, non ? Ceux qui ont un truc comme ça sont censés avoir les compétences pour adapter mes explications à leur cas, sinon pour s'en passer, je dirais.

Non, pas particulièrement ; c’est le comportement par défaut de ma distribution.

Message 6, par Elzen

§ Posté le 14/01/2013 à 1h 41m 06

Oui, donc c'est un réglage spécifique de ton système 😋


(Pas un réglage que tu as fait toi, mais un réglage qu'on retrouve sur ton système et pas trop ailleurs)


Tu es sous Arch, non ? Les utilisateurs d'Arch n'ont pas trop besoin de mes conseils, en théorie ^^

Envoyer une réponse