En prenant soin de lire le FHS, on découvre que le répertoire /opt concerne les logiciels non inclus dans la distribution et installés manuellement pour tous les utilisateurs.. Dans la pratique on y trouve effectivement nombre d’outils et progiciels. Ce répertoire /opt est loin d’être anecdotique dans une exploitation, c’est même un des viviers principaux des processus tournant sur une machine ! Certes j’exagère…
Or de base la sécurisation de ce répertoire /opt est très strict avec pour propriétaire et groupe respectivement root et root. Et donc se pose la question des droits à appliquer pour l’ensemble de ces applications et outils exotiques. Doit-on « tout passer en root » !?
Surtout pas malheureux ! Repeindre ses répertoires en root est une très mauvaise idée, pour deux raisons principales. Une telle stratégie revient à uniformiser sa sécurisation, ce qui est déjà un premier mauvais point sur un sujet qui demande au contraire de la granularité. J’ose l’apostrophe : si le sticky bit a été inventé, ce n’est pas pour qu’on uniformise les propriétés !
Ensuite ça imposerait de faire appartenir au groupe root les comptes utilisateurs des installations dans le /opt, ce qui revient à entre-ouvrir la porte du chaos.
Alors comment procéder ? Le point d’achoppement du précédent paragraphe est que le groupe propriétaire est le très particulier root. S’il était tout autre, nous lèverions toutes les réserves. La solution est là ! Pour ma part, j’ai pour habitude de créer un groupe opt pour ce qui concerne la gestion du répertoire /opt. Sa raison d’être est de qualifier les comptes pouvant accéder à ce qui suit dans l’arborescence, soit en pratique les comptes des applications installées dans ce fameux répertoire.
Cette mise en place est une bijection. C’est-à-dire que tout compte faisant partie du groupe opt est un compte d’une des applications installée dans /opt, et inversement tout compte d’une applications installée dans /opt fait partie du groupe opt. Et aucun autre.