Problèmes de droits avec les users/groupe/other

hornetovore · Le 18/07/2016, à 01:09

Bonsoir,

Je me retrouve confronté à un problème qui défie ma logique ! Un peu d'aide me serait d'un grand secours du coup.

J'ai 3 utilisateurs : user1, user2 et user3,
J'ai pour chacun de ces user un répertoire dans /home et j'ai un répertoire commun à tout le monde.

J'ai donc créé un script qui lance ces lignes de commande :

#user1
chmod -Rf 750 /home/user1 > /home/user1/scripts/droit.log
chown -Rf user1:root /home/user1 >/home/user1/scripts/droit.log

#user2
chmod -Rf 750 /home/user2> /home/user2/scripts/droit.log
chown -Rf user2:commun /home/user2> /home/user2/scripts/droit.log

#user3
chmod -Rf 750 /home/user3> /home/user3/scripts/droit.log
chown -Rf user3:commun /home/user3> /home/user3/scripts/droit.log

#PARTAGE
chmod -Rf 775 /home/partage > /home/user1/scripts/droit.log
chown -Rf user1:commun /home/partage > /home/user1/scripts/droit.log

#GESTION
chmod -Rf 700 /home/gestion
chown -Rf www-data:root /home/gestion

chmod -Rf 777 /home/gestion/temp

#DIVERS
chmod -Rf 777 /home/partage/divers > /home/user1/scripts/droit.log

Lorsque je lance le script, il n'y à pas de retour d'erreur, j'ai bien entendu créé un groupe nommé "commun" et y ai ajouté les différents utilisateurs.

cat /etc/group

me retourne bien une ligne avec

commun:x:1003:user1,user2,user3,www-data,debian-transmission,minidlna

(On y voit aussi www-data pour permettre d'accéder via un site web, transmission pour du partage via torrent et minidlna pour partager sur le réseau local)

Dans l'idée je cherche à ce que user1 (2 ou 3) aie un accès total à sa partie, qu'il puisse voir/lire les parties des autres sans pouvoir modifier et pour finir, avoir accès au dossier partage librement en écriture/lecture.

Le problème :

Dans la situation actuelle, une fois le script lancé, j'ai user1 et user2 qui fonctionnent comme il faut, ils ont les accès comme demandé par contre, user3 à bien son accès en lecture/écriture sur son dossier mais n'as qu'un accès en lecture sur le dossier partage, comme s'il était considéré comme "other" au lieu d'être considéré comme membre du groupe "commun", groupe qui à les droits en full...
J'ai aussi dans le groupe "commun" l'utilisateur "www-data" pour la gestion via mes pages web et là aussi, cet utilisateur est considéré comme faisant partie de "other" et non du groupe "commun", je peux lire mais aucun accès en écriture sauf sur le dossier "divers" qui est en droit 777.

Pourquoi user1 et user2 sont comme il faut alors que user3 et www-data ne sont pas pris en compte comme faisant partie du groupe "commun" ?

Coeur Noir · Le 18/07/2016, à 03:16

Un problème avec les droits d’exécution sur les dossiers ?

Voir, vers la fin de https://doc.ubuntu-fr.org/permissions#m … ermissions cet exemple :

doc permissions a écrit :

Application 1 :
Soit un répertoire monrep, contenant des sous-répertoires et des fichiers. Les droits sont drwx—— (700) pour les répertoires et -rw——- (600) pour les fichiers.
On veut ajouter récursivement les mêmes droits (resp. rwx et rw) pour le groupe. C'est à dire que veut aboutir à la situation suivante : drwxrwx— (770) pour les répertoires et -rw-rw—- (660) pour les fichiers.
Si on lance chmod -R 770 monrep : les fichiers vont avoir les droits d'exécution → mauvais :-(
Si on lance chmod -R 660 monrep : les répertoires n'auront plus les droits d'exécution → catastrophique :-(
Si on lance chmod -R g+rwx monrep : les fichiers vont avoir les droits d'exécution → mauvais :-(
Si on lance chmod -R g+rwX monrep : seuls les répertoires (et les fichiers déjà exécutables) auront les droits d'exécution → bon :-)
Application 2 :
Imaginons que précédemment on ait lancé la commande chmod -R 770 monrep. La situation est la suivante : les droits sont drwxrwx— (770) pour les répertoires et -rwxrwx—- (770) pour les fichiers.
On désire supprimer les droits d'exécution uniquement sur les fichiers. C'est à dire que veut aboutir à la situation suivante : drwxrwx— (770) pour les répertoires et -rw-rw—- (660) pour les fichiers.
Comme chmod s'applique à la fois aux fichiers et répertoires, nous allons jongler avec x et X. Il faut enlever x puis ajouter X.
Si on lance chmod -R u-x+X,g-x+X monrep cela n'aura aucun effet car X concerne à la fois les répertoires ET les fichiers qui ont un x quelque part. Donc si u-x enlève le premier x (ce qui donne -rw-rwx—), la suite +X va aussitôt remettre un x car il reste un x (celui du groupe !).
Donc il faut d'abord enlever tous les x : u-x,g-x avant de les remettre (sera fait uniquement pour les répertoires cette fois) ce qui donne finalement :
chmod -R u-x,g-x,u+X,g+X monrep

Dernière modification par Coeur Noir (Le 18/07/2016, à 03:21)

hornetovore · Le 18/07/2016, à 10:06

Bonjour,

J'ai suivi tes conseils et ai modifié mon script comme ceci :
un

chmod -R 400 /home/*

pour mettre un pied d'égalité suivi d'un

#U1
chmod -R u+rwX /home/user1
chown -R user1:root /home/user1

#U2
chmod -R u+rwX,g+rX /home/user2
chown -R user2:commun /home/user2

#U3
chmod -R u+rwX,g+rX /home/user3
chown -R user3:commun /home/user3

#PARTAGE
chmod -R u+rwX,g+rwX /home/partage
chown -R user1:commun /home/partage

#GESTION
chmod -R u+rwX /home/gestion
chown -R www-data:root /home/gestion

J'ai bien les droits d'execution uniquement pour les dossiers, mais le problème de départ reste le même, user 1 et 2 fonctionne comme il faut.

user3 lui à accès en lecture au dossier partage mais pas en écriture
www-data (le site) ne liste même plus le contenu du dossier partage, il n'as plus de droits en lecture apparemment...

EDIT: si je rajoute o+rX au dossier partage, le site peut à nouveau lister le contenu, ça confirme ce que je pensais,www-data n'est pas pris en compte comme étant membre du groupe commun...

Dernière modification par hornetovore (Le 18/07/2016, à 10:33)

erresse · Le 18/07/2016, à 11:56

D'origine, à la création, un compte utilisateur est construit ainsi :
drwxr-xr-x ... user user ... /home/user
Soit, les droits 755 et la propriété à "user", groupe "user".

Si tu affectes un groupe "commun" à tous tes comptes, tu auras donc :
drwxr-xr-x ... user1 commun ... /home/user1
drwxr-xr-x ... user2 commun ... /home/user2
drwxr-xr-x ... user3 commun ... /home/user3
Et que tu ajoutes tous tes utilisateurs au groupe "commun", tu auras donc :
commun:x:1003:user1,user2,user3,www-data,debian-transmission,minidlna

Cette configuration autorise chaque utilisateur à gérer son propre compte avec tous les droits, et à accéder aux comptes des autres utilisateurs en lecture / exécution seulement (droits du groupe "commun")

Si tu veux disposer d'un compte commun à tous les utilisateurs, dans lequel ils auront tous les droits, tu dois créer un compte :
drwxrwxr-x ... commun commun ... /home/commun
Soit, les droits 775 et la propriété à "commun", groupe "commun".
En ajoutant à ce compte le droit d'écriture au groupe, tous les utilisateurs pourront y lire et y écrire.

Est-ce que cela correspond à ce que tu veux obtenir ?

hornetovore · Le 18/07/2016, à 14:17

Erresse :

J'ai tout repris à zéro :
1: j'ai sorti les membres du groupe commun,
2: j'ai effacé ce groupe,
3: j'ai renommé mon dossier partage en partage2 pour ne pas perdre son contenu
4: j'ai créé un user avec

adduser partage

5: j'ai supprimé son dossier dans home et l'ai remplaçé par partage2 qui est redevenu partage
6: j'ai ajouté les user1,2,3, minidlna et debian-transmission au groupe avec

adduser <nom user> partage

7: j'ai attribué les droits comme énnoncé plus haut (750/640 par dossier /home, 770/660 pour partage)
8: Après un reboot des différents services, pour le moment tout semble être ok, il faut que je vérifie plus en profondeur.

Mais entre maintenant et avant, la seule différence est qu'avant j'avais un groupe (commun) créé sans avoir d'utilisateur, juste le groupe et donc sans dossier /home, c'est ça qui rendait le système de droits boiteux ????

Je cherche à comprendre pour y voir plus clair au cas où dans le futur...

Coeur Noir · Le 18/07/2016, à 15:43

Le retour de

ls -la /home

« groupe sans utilisateur du même nom » → nope, ça n'est pas un problème. Sur plusieurs installations que je « gère » j'ai des groupes maison, bureau, hall, archive, accueil… et pas d'utilisateurs avec ces noms.

Comment as-tu créé tes nouveaux groupes ? Dans l'appli' graphique "utilisateurs et groupes" ( du paquet gnome-system-tools ) il y a la notion de groupe principal associé à un utilisateur.
Je dirais plutôt que tes user3 et www-data avaient simplement par défaut user3 et www-data pour groupe principal, au lieu du groupe "commun". Ça correspond à l'option --ingroup de adduser

--ingroup GROUP
Add the new user to GROUP instead of a usergroup or the default
group defined by USERS_GID in the configuration file. This
affects the users primary group. To add additional groups, see
the add_extra_groups option

Et en re-manipulant ton group ( post #5 ) tu as probablement établi correctement un groupe principal. Et donc si je comprends bien pour créer un groupe, tu as en fait créé un nouvel utilisateur ( adduser partage ) ? Ça marche sous Ubuntu parceque par défaut la création d'un nouvel utilisateur entraîne la création d'un groupe du même nom. C'est réglé dans le fichier /etc/login.defs à la section USERGROUPS_ENAB

If set to yes, userdel will remove the user's group if it contains
no more members, and useradd will create by default a group with
the name of the user.

https://doc.ubuntu-fr.org/adduser#addgroup

Par ailleurs le umask par défaut du système est 022. Celui-ci influe sur la création des nouveaux fichiers/dossiers qui sont donc en 755, et de plus « useradd and newusers use this mask to set the mode of the home directory they create » donc en créant un nouvel user avec un home, ce home est en 755. Or si on veut donner des droits d'écriture à des groupes, ça va coincer ;-) umask se règle aussi dans /etc/login.defs le passer à 002 me paraît cohérent.

Enfin un autre truc qui pourrait t'intéresser c'est le bit sgid, afin que les fichiers créés dans un dossier héritent du groupe de ce dossier…

Dernière modification par Coeur Noir (Le 18/07/2016, à 15:45)

erresse · Le 18/07/2016, à 15:55

Je ne sais pas trop ce qui pouvait gêner dans ta construction, sinon que tu donnais l'accès à certains répertoires ou comptes au groupe "root", peut-être... Dans le répertoire /home, il n'y a pas de raison de placer des objets n'appartenant pas aux utilisateurs.
D'autant plus que, pour "root", peu importe la propriété d'un objet, il a accès à tous !

Je pense qu'il faut raisonner en tenant compte que :
- les droits d'accès, rwx pour propriétaire/groupe/autres, sont associés aux objets (répertoires ou fichiers).
- l'appartenance, propriétaire/groupe, est également associée aux objets et établit le lien avec les droits d'accès.
On peut voir ça comme la structure d'une entreprise, par exemple :
- Le groupe <=> un service
- L'utilisateur <=> un employé
- Les objets <=> les informations
Lorsqu'un employé rédige un rapport, il lui appartient en tant que créateur et appartient aussi au service dont l'employé dépend.
L'employé créateur aura donc un accès total à ses informations, et les autres employés du même service pourront aussi y avoir accès, mais peut-être avec des prérogatives restreintes.
D'autres personnes n'appartenant pas à ce service pourront éventuellement lire aussi ce rapport.
Il y a donc des droits pour le propriétaire, d'autres accordés aux autres membres du service, et d'autres encore différents pour les personnes extérieures.

En général, un employé appartient à un service, mais certains employés travaillent dans plusieurs services.
Ces employés-là ont un badge leur permettant d'entrer dans les différents services auxquels ils ont accès, et d'y intervenir sur les informations gérées par ces services. Avec, peut-être le droit de lire seulement certaines informations, mais aussi d'en modifier...

Enfin, il y a des lieux qui sont ouverts à tous, par exemple la cafétéria, et si on veut que tout un chacun puisse lire et modifier à son gré une information, on va la laisser traîner là, sous les yeux (et les mains) de quiconque.

Chaque groupe recensera donc la liste des utilisateurs qui y participent, un même utilisateur pouvant apparaître dans plusieurs groupes.
Lorsqu'un groupe est associé à un objet, tous les participants de ce groupe bénéficient des droits que le groupe a sur cet objet.
Les droits sont de plus en plus restrictifs en allant du propriétaire au groupe puis aux autres : si on mettait des droits "--- --- rwx" à un objet, ce serait absurde car ni le propriétaire ni le groupe n'auraient accès à l'objet, mais il serait accessible par tout le monde et donc, par voie de conséquence au propriétaire et au groupe !?!

Voilà, j'espère que mon exposé pourra t'éclairer sur cette gestion des droits et propriétés des objets.
Une pensée gagnante à tous les coups : Toujours aller au plus évident. Plus c'est simple, plus ça a des chances de marcher !

Compte anonymisé · Le 18/07/2016, à 22:37

erresse a écrit :

Les droits sont de plus en plus restrictifs en allant du propriétaire au groupe puis aux autres : si on mettait des droits "--- --- rwx" à un objet, ce serait absurde car ni le propriétaire ni le groupe n'auraient accès à l'objet, mais il serait accessible par tout le monde et donc, par voie de conséquence au propriétaire et au groupe !?!

bonjour, simplement une remarque:

les autres (o) ce n'est pas pareil que tout le monde mais bel et bien les autres, alors si le répertoire ou fichier est à --- --- rwx ce n'est pas tout le monde qui aura accès mais les autres, le propriétaire et le groupe n'auront pas accès, ce n'est pas absurbe par le fait puisque la cohérence est respectée.

Dernière modification par Compte anonymisé (Le 18/07/2016, à 22:39)

erresse · Le 19/07/2016, à 11:33

@Localhost:
Merci de tes précisions. Effectivement, les droits affectés à "Autres" ne s'appliquent pas au propriétaire ou au groupe de l'objet.
L'appartenance à une catégorie d'utilisateur vis à vis des droits d'accès est donc exclusive ("autres" exclue de fait "propriétaire" et "groupe").
En disant que c'était absurde, je pensais simplement au fait qu'un utilisateur crée un objet en s'interdisant d'y avoir accès...
Mais sur le plan de la cohérence, je reconnais que tu as tout à fait raison.

hornetovore · Le 21/07/2016, à 10:54

Merci beaucoup pour toutes ces précisions, je prend du temps à répondre pour être sur de ne rien oublier et ne pas relancer le sujet 20 fois !

J'avais un problème d'écriture via un script sur le site web (upload d'image) mais ça c'est résolu tout seul le lendemain, je n'ai donc pas pu voi/comprendre où était le souci.

J'ai encore (du moins hier, il faut que je vérifie aujourd'hui) un problème avec minidlna, le serveur DLNA est accessible mais ne supporte pas la suppression...

Pour le reste, les users fonctionnent correctement !

Coeur Noir a écrit :

Le retour de
Comment as-tu créé tes nouveaux groupes ? Dans l'appli' graphique "utilisateurs et groupes" ( du paquet gnome-system-tools ) il y a la notion de groupe principal associé à un utilisateur.

Je suis sous serveur 14.04.4 LTS donc sans interface graphique, j'ai à l'époque créé mon groupe commun avec un

addgroup commun

Coeur Noir a écrit :

Je dirais plutôt que tes user3 et www-data avaient simplement par défaut user3 et www-data pour groupe principal, au lieu du groupe "commun". Ça correspond à l'option --ingroup de adduser
--ingroup GROUP
Add the new user to GROUP instead of a usergroup or the default
group defined by USERS_GID in the configuration file. This
affects the users primary group. To add additional groups, see
the add_extra_groups option

J'avais pourtant bien fait un

adduser www-data commun && adduser userX commun

, les différents users apparaissaient dans la ligne concernant le groupe commun lors d'un

cat /etc/group

, je ne comprend pas...

Coeur Noir a écrit :

Et en re-manipulant ton group ( post #5 ) tu as probablement établi correctement un groupe principal. Et donc si je comprends bien pour créer un groupe, tu as en fait créé un nouvel utilisateur ( adduser partage ) ?

Oui.

Coeur Noir a écrit :

Par ailleurs le umask par défaut du système est 022. Celui-ci influe sur la création des nouveaux fichiers/dossiers qui sont donc en 755, et de plus « useradd and newusers use this mask to set the mode of the home directory they create » donc en créant un nouvel user avec un home, ce home est en 755. Or si on veut donner des droits d'écriture à des groupes, ça va coincer ;-) umask se règle aussi dans /etc/login.defs le passer à 002 me paraît cohérent.

En effet, mais j'ai pour parer à ça et pour régler plus précisément les droits selon les répertoires fais le script "de droits" qui est appelé par cron toutes les X minutes, les fichiers peuvent donc être créés par n'importe quel users, root viens réajuster les droits et appartenance automatiquement.

Je vais voir si le problème d'écriture (suppression) via l'user minidlna continue, j'ai dé-commenté la ligne

#user=minidlna

afin d'être sur que le service est lancé par son propre utilisateur (logiquement c'était déjà le cas), minidlna est bien présent dans le groupe partage (cat /etc/group), je ne vois pas ce qui peut poser le souci avec cet utilisateur uniquement !

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 18/07/2016, à 01:09

Problèmes de droits avec les users/groupe/other

#2 Le 18/07/2016, à 03:16

Re : Problèmes de droits avec les users/groupe/other

#3 Le 18/07/2016, à 10:06

Re : Problèmes de droits avec les users/groupe/other

#4 Le 18/07/2016, à 11:56

Re : Problèmes de droits avec les users/groupe/other

#5 Le 18/07/2016, à 14:17

Re : Problèmes de droits avec les users/groupe/other

#6 Le 18/07/2016, à 15:43

Re : Problèmes de droits avec les users/groupe/other

#7 Le 18/07/2016, à 15:55

Re : Problèmes de droits avec les users/groupe/other

#8 Le 18/07/2016, à 22:37

Re : Problèmes de droits avec les users/groupe/other

#9 Le 19/07/2016, à 11:33

Re : Problèmes de droits avec les users/groupe/other

#10 Le 21/07/2016, à 10:54

Re : Problèmes de droits avec les users/groupe/other

Pied de page des forums