Après avoir effectué quelques recherches et tests infructueux je me permets de solliciter un peu de votre temps et de votre aide.
Ayant décidé d’avoir une configuration un peu personnalisée d’Apache (pour faire du développement web, à la place du traditionnel lampp) j’ai compilé et installé tous les paquets et sources nécessaires au bon fonctionnement de mon environnement de dev’.
Le seul soucis, c’est que je n’ai pas la possibilité de lancer apache et d’écrire dans mon dossier htdocs (plus connu généralement sous le chemin /var/www) sans être root. A la rigueur pour lancer le serveur ce n’est pas un soucis en revanche , pour écrire et modifier des fichiers de pages web c’est problématique.
J’ai pensé, comme le dossier appartient au groupe root, à créer un groupe dev, à l’associer à ce nouveau groupe et rajouter root (qui reste propriétaire du dossier) et mon compte dev’ avec les mêmes droits (c’est à dire tous) pour le propriétaire et le groupe. Mais rien n’y fait, je n’ai toujours pas la possibilité d’écrire (voire même de rentrer dans le dossier). La seule solution qui marchait était de changer le propriétaire du groupe, mais je suspecte que ce ne soit pas une bonne idée de changer les dossiers/fichiers qui appartiennent à root par des comptes “normaux”.
De plus après avoir essayé, pour vérifier s’il n’y avait pas des spécificités aux dossiers se trouvant dans /etc, de créer un dossier avec root dans le home de mon utilisateur dev’ en lui adjoignant groupe et droits comme plus haut, j’ai rencontrer les mêmes difficultés.
Connaitriez-vous l’origine de ce problème et comment le résoudre ? J’ai rencontrer le même problème avec Docker sans pouvoir le régler. De plus je souhaiterais avoir une précision sur quelque chose d’un peu nébuleux pour moi, dans le cas d’un dossier comme apache2, que change l’option x pour un dossier (à l’inverse d’un fichier) ?
Donc si tu as les droits « d’exécution » sur tous les dossiers parents de /a/b/c et tous les droits sur /a/b/c, tu peux accéder et faire ce que tu veux sur /a/b/c, mais si tu ne les as pas sur /a/b, tu ne peux pas accéder à /a/b/c.
Le droit de lecture sur un dossier permet de voir ce qu’il contient (la liste des fichiers et leurs attributs).
Pour la question initiale, tu t’es déconnecté / reconnecté depuis que tu t’es ajouté au groupe dev ?
Chez moi, tout mon site se trouve dans /var/www
Tous les dossiers qui sont dans /var/www/… sont “root:www-data” et avec des droits 750, càd d.rwxr-x—
En admettant qu’il en soit de même pour toi, tu peux :
1/ mettre les dossiers sur lesquels tu désires intervenir en tant qu’user -et seulement ceux-là- en 770
2/ mettre ton user dans le groupe www-data
Il convient d’avoir un MDP user en béton, évidemment.
Tu peux aussi placer ton user dans sudoers et, éventuellement configurer ce dernier de façon à ce qu’il ne soit ouvert que pour les dossiers concernés.
[quote=“Wayzee, post:1, topic:73149”]
J’ai pensé, comme le dossier appartient au groupe root, à créer un groupe dev, à l’associer à ce nouveau groupe et rajouter root (qui reste propriétaire du dossier) et mon compte dev’ avec les mêmes droits (c’est à dire tous) pour le propriétaire et le groupe. Mais rien n’y fait, je n’ai toujours pas la possibilité d’écrire (voire même de rentrer dans le dossier).[/quote]
Je trouve tout ça bien brouillon… Tu devrais créer un utilisateur et groupe dédié à ton apache. Une fois que c’est fait, change les droits (utilisateur et groupe) sur ton dossier et lance ton apache avec l’utilisateur en question.
Normalement à partir de là, tu te retrouve avec un conf’ “classique”.
[quote=“Wayzee, post:1, topic:73149”]
La seule solution qui marchait était de changer le propriétaire du groupe, mais je suspecte que ce ne soit pas une bonne idée de changer les dossiers/fichiers qui appartiennent à root par des comptes “normaux”. [/quote]
Disons que c’est mieux que de le faire tourner en root… Avec la bonne commande CGI ou PHP par exemple, tu pourrais facilement casser ton système (ex: <?php system("/bin/rm /*"); ?>).
[quote=“Wayzee, post:1, topic:73149”]
De plus après avoir essayé, pour vérifier s’il n’y avait pas des spécificités aux dossiers se trouvant dans /etc, de créer un dossier avec root dans le home de mon utilisateur dev’ en lui adjoignant groupe et droits comme plus haut, j’ai rencontrer les mêmes difficultés.[/quote]
Désolé, mais je n’ai absolument rien compris à cette partie.
[quote=“Wayzee, post:1, topic:73149”]
De plus je souhaiterais avoir une précision sur quelque chose d’un peu nébuleux pour moi, dans le cas d’un dossier comme apache2, que change l’option x pour un dossier (à l’inverse d’un fichier) ?[/quote]
Cela permet de “traverser” le dossier, et donc de voir ce qu’il y a en dessous.
@David_5.1 pour le coup je n’y ai pas pensé mais après avoir redemarrer, du moins arreté à cause de l’heure tardive et être revenu, cela semblait fonctionner. Il ne me semblait pas nécessaire de devoir me déloguer et reloguer pour que le changement soit pris en compte.
@anonyme2
Lorsque que je fais un ls -l sur var
J’ai la ligne suivante pour le dossier local
drwxrwsr-x 2 root staffs 4096 et les dates.
@ricardo
Chez moi ils sont dans un dossier différent /usr/local/apache2/htdocs, quand j’étais sur windows mais dossier étaient également dans un htdocs donc ça ne me semble pas étrange… ça l’est ?
C’est un peu ce que j’essayais de faire mais au début ça ne marchait pas mais ça semble être le cas.
J’avais également regarder sudoers, notamment pour pouvoir permettre le lancement d’Apache sans être root, et j’avais du coup compris que ça fonctionnait principalement pour les commandes du coup, si je veux le faire avec des dossiers aurais-tu des pistes à me suggérer ? J’aurais l’idée de tenter basiquement l’autorisation d’un touch, un mkdir mais étant donné que je n’utilise pas vraiment Vim ou Nano pour développer, je n’ai aucune idée de comment fonctionne le mécanisme de création d’un fichier avec un programme externe (SublimText et Eclipse entre autre).
@sk4hrr
Si je comprends bien une configuration classique on aurait, un utilisateur par application ? N’est-il pas plus simple d’avoir des groupes dans lesquels on peut inclure des utilisateurs plutôt ? Car si j’ai un serveur et d’autres programmes (base de données par exemple) et que je dois me connecter à chaque fois avec un utilisateur différent ça risque de devenir un peu laborieux j’ai l’impression.
Concernant la deuxième j’ai sans doute manqué de clarté, j’expliquais juste que j’avais fait un test avec un dossier lambda créer en root et que j’avais changé son groupe (créer pour l’occasion) et que dans ce groupe j’avais ajouté un autre utilisateur et que j’y avais adjoint les mêmes droits que ceux dont disposait son utilisateur(root).
Ici je fais référence à des contraintes particulières, étant relativement nouveau sur linux (pour l’aspect “administration/system” tout du moins), qu’il pourrait y avoir sur des dossiers de types systèmes dont je n’aurais pas connaissance.
Par ailleurs cela m’amène à poser une autre question sur les groupes et leurs gestions. Existe-t-il une possibilité de voir à quels dossiers / actions des groupes sont associés ?
Durant mes recherches je vois souvent que certains programmes s’installent en créant des groupes (voire utilisateurs) afin de pouvoir effectuer certaines actions (Docker ou mysql par exemple). Hors ne connaissant pas les groupes “de base”, lorsque je vois un dossier associer à un groupe qui ne m’est pas familier, en dehors d’une recherche sur un moteur de recherche, qui peut ne pas être fructueuse, je n’ai aucune possibilité de savoir à quoi peut servir ce groupe. Je peux en lister les utilisateurs et faire une correlation, mais ça ne fonctionne pas toujours.
La question me vient car j’ai un groupe “staffs” associer à mon répertoire /usr/local sans savoir réellement à quoi il correspond, je ne l’ai pas créer moi même (bien qu’associer à mon compte) sachant que root n’en fait pas partie. Du coup si je veux faire le moindre changement, associer certains dossiers et utilsateurs à un groupe dédier au développement par exemple (bien que je me demande encore une fois si la centralisation est une bonne chose, car les programmes n’ont pas nécessairement les mêmes besoin, si un programme A a besoin d’accéder au sockets alors que le programme B veut juste pouvoir écrire dans tel dossier tout comme le programme A), ne connaissant pas les “spécificités” du groupes voire des utilisateurs, je me demande justement s’il existe une manière de pouvoir le faire (autre que le premier truc qui me passerait par la tete : lister tous les dossiers depuis la racine et faire un tri sur le nom des groupes).
Je m’excuse par avance si je suis un peu long à lire! Quoi qu’il en soit mon problème initial est réglé mais comme j’ai encore quelques questions qui substistent, je me permets de ne pas cloturer le sujet tout de suite
Comme tu le dis toi-même un peu plus bas dans ta réponse, beaucoup de démons tournent avec un utilisateur et groupe dédié. Disons que c’est une des bases en sécurité: cloisonner.
Pour ton idée de groupe, elle n’est pas mauvaise, mais imaginons que l’utilisateur apache et celui de mysql sont dans le même groupe, alors si ton apache est compromis pour une raison x ou y, il pourra supprimer les fichiers de ton mysql. C’est un exemple basique, mais je pense qu’il montre bien l’intérêt d’avoir un utilisateur/groupe par démon.
La commande suivante semble faire l’affaire (source): find / -user username -ls
C’est un groupe système, utilisé par Debian, donc pas de raison de s’en inquiéter. En fait, les seuls droits sur lesquels il faut sérieusement réfléchir, c’est ceux sur des fichiers/dossiers qu’on a créer soit-même. Debian est plutôt bien loti en terme de sécurité
Le mieux c’est de positionner les droits dans une sous-arborescence que tu maîtrise complètement, comme par exemple /var/www/mon_presta1.
Si ce sont des programmes que tu as créé ou tiers, un groupe commun aux deux fait parfaitement l’affaire. Si ce sont des paquets, normalement c’est prévu.
Merci pour toutes ces réponses qui m’apportent beaucoup!
Au risque de paraître un peu entêté, je conçois bien le principe de cloisonnement, mais du coup plutôt que d’avoir un groupe dev’ auquel je rattacherais les dossiers liés à Apache, qui sont rattachés au groupe staff (ne connaissant pas exactement les attributions du groupe staff et les conséquences d’un changement de ce point de vue ; j’ai par ailleurs merci pour la commande avec find elle marche bien, je pense que je pourrais l’améliorer encore pour affiner certains points ; je préfère ne pas m’y risquer tant que je n’en connais pas les conséquences et les risques) sachant que changer le propriétaire des fichiers/dossiers n’est pas non plus une bonne solution, est-ce que rajouter le compte créer principalement pour faire du dev’ (si j’ai plusieurs programmes/dossiers que j’ai besoin de manipuler depuis ce compte) surtout dans le cas où se sont des paquets qui sont installés avec des groupes/users associés peut être une solution intéressante/sécurisé ?
Surtout que si j’ai besoin régulièrement de faire des opérations nécessitant (exemple de base de données) des opérations avancées, je ne vois pas comment me connecter au compte en question (mysql par exemple) et je ne pense pas que ce soit une idée judicieuse.
Par hasard la notion de propriétaire de groupe existe-t-elle (par exemple comment savoir qui a crée un groupe et si il en est le propriétaire et peux changer les propriétés du groupe) ?
Dans le cas de la solution /var/www/mon_site que je trouve intéressante, le mieux serait de créer un dossier de ce type (qui n’existe pas chez moi) et de rediriger mes requêtes dans apache pour ce dossier ou de créer un dossier dans le répertoire qui existe déjà à cet effet (apache2/htdocs/www/mon_site par exemple) ? Quelle solution est la meilleure et pourquoi ?
Bien évidemment, tu as auparavant modifié la directive DIR_MODE=0755 du fichier /etc/adduser.conf et modifié les permissions sur les répertoires de tes utilisateurs dans /home qui sont par défaut en rwxr-xr-x (0755) ?
Et adapté le umask pour que quand l’utilisateur root ou autre crée un fichier il ne soit pas visible par tout le monde ?
Avant de te lire, je n’en n’avais jamais entendu parlé…
Si j’ai bien compris les pages du manuel, DIR_MODE indique avec quelles permissions des fichiers et des répertoires doivent être créés par défaut ? Par contre je n’ai pas compris le lien avec umask et pas vraiment, son utilité / fonctionnement par rapport à la gestion des droits.
Si tu pouvais m’éclairer j’apprécierais grandement ^^
Edit : Après avoir fait d’autres recherches, tu me corrigeras si je me trompe, DIR_MODE définit avec quels droits vont être créés l’ensemble des dossiers pour tous les utilisateurs (root y compris) et umask permet d’affiner ces droits individuellement pour chaque utilisateurs. C’est bien cela?
Si oui, quel intérêt (autre que pour des raisons de “sécurités”), il faudrait que je modifie les permissions dans /home ?
Lorsque que root (ou un autre utilisateur) crée un fichier/répertoire avec quels droits faudrait-il qu’ils ne soient pas visible ? 700 ou 750 ? Si oui le fichier est-il considéré comme un fichier caché(qui pourrait ne pas être visible avec un ls -l ou alors l’impossibilité, si cela est possible de ne pas pouvoir exécuter de commande lorsque l’on est dans un répertoire dans lequel on a pas les droits d’exécution comme pour fichier, bien que j’ai l’impression de dire une bêtise sur ce point là) du point de vue d’un autre utilisateur ou il est simplement invisible (par un mécanisme qui me serait obscure) ?
En fait, DIR_MODE dans /etc/adduser.conf permet de définir les permissions avec lesquelles un dossier pour un nouvel utilisateur sera créé dans /home .
Par défaut la permission étant 0755 , ce qui correspond à rwxr-xr-x, lorsque tu crée un user toto avec la commande adduser ou une interface graphique quelconque, n’importe-quel autre user pour lister le contenu du répertoire /home/toto .
Le umask est un “masque” qui permet d’enlever des permissions par rapport à 777 (rwxrwxrwx) lorsqu’un utilisateur crée un fichier.
Par exemple, sur une Debian Jessie il vaut 022, par défaut. Ce qui veut dire qu’un nouveau fichier (ou répertoire) qu’un utilisateur crée aura des permissions valant 755 (rwxr-xr-x). Même si pour les fichiers normaux, les permissions d’exécution sont généralement enlevées, donc 644 (rw-r–r--).
Si on reconfigurait le umask à 077, admettons, un fichier nouvellement créé aurait des permissions valant 700 (rwx------) et sans le bit d’exécution 600 (rw-------).
Ceci fait que par défaut sous Debian avec le home de l’utilisateur créé en 755 (rwxr-xr-x) et un umask de 022 … si tu crées un sous-répertoire perso avec un fichier login_meetic.txt et que ton petit-frère a un compte sur le système, il pourra tout à fait aller lire son contenu.
Et c’est pourquoi passer DIR_MODE à 750, par exemple, est la première chose que l’on fait sur un Debian a sécuriser.
La seconde chose, c’est faire un chmod 750 /home/toto sur le répertoire home de l’utilisateur créé lors de l’installation de Debian.
