Droits et différence entre groupe root et groupe adm

en essayant de comprendre pourquoi je peux afficher /etc/apt/sources.list avec firefox mais que l’affichage de /var/log/kern.log est refusé j’ai regardé du côté des droits .

mm@mm:~$ ls -l /var/log/kern.log
-rw-r----- 1 root adm 927  2 août  15:06 /var/log/kern.log
mm@mm:~$ ls -l /etc/apt/sources.list
-rw-r--r-- 1 root root 952  3 juil. 12:42 /etc/apt/sources.list

Hormis les tailles et le 3ème « r » de sources.list je ne vois que les groupes root et adm qui soient différents et il semblerait que malgré des droits quasi identiques l’appartenance au groupe adm est plus restrictive que l’appartenance à root . À moins que ce soit le droit « r » qui manque qui en est la cause ?

En dépit des explications fournies par duckduckgo ça reste encore très flou pour moi et même si ça ne m’est pas indispensable j’aimerais bien y voir un peu plus clair .

  • je crois avoir compris car le dernier droit « r » est relatif à « autres utilisateurs » et j’ai mélangé " utilisateur propiétaire" ( =root) avec « groupe propriétaire » ( root ou adm )quis sont donc 2 choses différentes . Ensuite viennent les autres utilisateurs , donc mm qui n’a pas le droit « r » donc ne peut pas afficher .

  • reste cette hidtoire de root et adm

il y a trois groupes de trois bits de mode : O G A <=> Owner Group All

  • le premier groupe de bits de mode (le plus à gauche) concerne le propriétaire <=> Owner
  • le deuxième concerne le groupe <=> Group
  • et le troisième, tous <=> All

On voit, dans la liste des bits de mode du fichier /etc/apt/sources.list, le bit de mode r (read) dans le groupe All ce qui signifie que tout le monde peut avoir accès en lecture à ce fichier.

Par contre, dans la liste des bits de mode du fichier /var/log/kern.log, le bits de mode r n’est présent que dans les groupes de bits de mode concernant le propriétaire (root) de ce fichier et le groupe (adm)

Donc, à part le propriétaire de ce fichier, qui est root, seuls les comptes utilisateurs qui sont dans la liste des comptes utilisateurs du groupe adm pourront accéder en lecture au fichier
/var/log/kern.log


Voir aussi : File permissions and attributes - ArchWiki


EDIT : j’avais fait une confusion concernant les noms des trois groupes parce que j’avais en tête le nom des options utilisables par la commande de modification des bits de mode qui est la commande chmod

Pour voir les pages du manuel de la commande chmod
lançer la ligne de commande suivante :

man chmod

entre temps j’avais trouvé un site qui expliquait clairement la situation et me donnait la signification de u , g et o ce qui m’avait permis de comprendre : Droits sous Linux : Utilisateurs, Groupes, Permissions - Wiki - Wiki

Quant à ce groupe adm je le laisse vivre sa vie sans m’en inquiéter plus avant .

merci pour la réponse .

Entre temps, j’ai modifié mon message précédent et renommé les groupes de bits de mode correctement.
(et je vois, dans la page web que tu cites, qu’ils ont fait la même erreur que je viens de corriger)

Voir la note que j’ai ajoutée en bas de mon message précédent pour comprendre d’où provenait cette confusion.

sur Archwiki je lis ceci :

  • u : the [user] that owns the file.
  • g : the [user group]that the file belongs to.
  • o : the o other users, i.e. everyone else.
  • a : a all of the above; use this instead of typing ugo .

L’extrait ci-dessus que tu cites dans ton message est un extrait du paragraphe Changing permissions,
et donc, ces lettres (ugoa) ne concernent que la commande chmod,
d’où la confusion entre les lettres :

  • ugoa (utilisées comme options possibles de la commande chmod)

et les lettres :

  • oga (utilisées pour nommer les 3 groupes de bits de mode d’un fichier)

La lettre o dans le contexte de la commande chmod
n’a plus du tout la même signification quand elle est utilisée pour nommer un groupe de bits de mode d’un fichier.

La lettre a dans le contexte de la commande chmod
n’a plus du tout la même signification quand elle est utilisée pour nommer un groupe de bits de mode d’un fichier.

pourquoi faire simple quand on peut faire embrouillé ?

Il est extrêmement difficile d’arriver à faire des choses très simples à utiliser.

et donc , si je ne me trompe pas , le site qui m’avait éclairé est tombé dans le piège ugo :

### Lire ses droits
rwxr-xr--
\ /\ /\ /
 v  v  v
 |  |  droits des autres utilisateurs (o)
 |  |
 |  droits des utilisateurs appartenant au groupe (g)
 |
 droits du propriétaire (u)

Oui, c’est ce que j’écrivais dans l’extrait d’un de mes messages :

il faudrait que je m’astreigne à plus de rigueur ça m’éviterait :

  1. des remarques inutiles
  1. de faire perdre du temps aux bonnes volontés

merci pour toutes ces explications

Je recommande la page wiki de archlinux.org qui est très bien détaillée et dans laquelle on trouve des liens en bas de page qui renvoient sur d’autres pages web toutes aussi bien faites qui aident à dissiper certaines confusions.


Après avoir installé le paquetage info
voir aussi le retour de la ligne de commande suivante :

info Coreutils -n "File permissions"

Il y a tellement de possibilités d’affectation de droits, que tu peux considérer que les 3 groupes de rwx sont déjà une sacrée simplification.
Pour jouer au loto avec les combinaisons chiffrées de rwx, il faut demander au hollandais volant.
»» Calculer un Chmod - le hollandais volant

Un conseil: ne joue pas au loto avec des droits de fichiers système sans être parfaitement sûr de ce que tu modifies…

Sans compter les bits d’attributs modifiables par la commande chattr ni les règles ACL
il y a 8⁴ <=> 4096 combinaisons possibles.


Dans la page web citée,
il manque le quatrième rang des bits de mode en mode octal (qu’il a labellisé numéral)

michel@deb114x1t:~$ touch aeffacer && chmod 0000 aeffacer   # Créer le fichier 'aeffacer' et mettre à zéro tous ses bits de mode
michel@deb114x1t:~$ 
michel@deb114x1t:~$ stat --printf='%04a\t%A\t%n\n' aeffacer   # Afficher les bits de mode de 'aeffacer' en mode octal et 'humain'
0000	----------	aeffacer
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose a+x  aeffacer           # Activer le bit de mode d'exécution (x) de 'aeffacer' pour le propriétaire (owner), le groupe (group) et tous (all)
le mode de 'aeffacer' a été modifié de 0000 (---------) en 0111 (--x--x--x)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose  +t  aeffacer           # Activer le bit de mode 'sticky bit' de 'aeffacer'
le mode de 'aeffacer' a été modifié de 0111 (--x--x--x) en 1111 (--x--x--t)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose o-x  aeffacer           # Désactiver le bit de mode d'exécution (x) de 'aeffacer' pour tous (all)
le mode de 'aeffacer' a été modifié de 1111 (--x--x--t) en 1110 (--x--x--T)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose g+s  aeffacer           # Activer le bit de mode 'set uid' de 'aeffacer' pour le groupe (group)
le mode de 'aeffacer' a été modifié de 1110 (--x--x--T) en 3110 (--x--s--T)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose g-x  aeffacer           # Désactiver le bit de mode d'exécution (x) de 'aeffacer' pour le groupe (group)
le mode de 'aeffacer' a été modifié de 3110 (--x--s--T) en 3100 (--x--S--T)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose u+s  aeffacer           # Activer le bit de mode 'set uid' de 'aeffacer' pour le propriétaire (owner)
le mode de 'aeffacer' a été modifié de 3100 (--x--S--T) en 7100 (--s--S--T)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ chmod --verbose u-x  aeffacer           # Désactiver le bit de mode d'exécution (x) de 'aeffacer' pour le propriétaire (owner)
le mode de 'aeffacer' a été modifié de 7100 (--s--S--T) en 7000 (--S--S--T)
michel@deb114x1t:~$ 
michel@deb114x1t:~$ stat --printf='%04a\t%A\t%n\n' aeffacer   # Afficher les bits de mode de 'aeffacer' en mode octal et 'humain'
7000	---S--S--T	aeffacer
michel@deb114x1t:~$ 

Non non non, infiniment moins… Il faut corriger ta documentation.

En détails, pour chaque groupe, on calcul le chiffre correspondant aux permissions :
R = 4 (read)
W = 2 (write)
X = 1 (execute)

Donc si on veut donner les permissions rwx rw- -wx à un fichier, on code comme suit :
• rwx : 4+2+1=7
• rw- : 4+2+0=6
• -wx : 0+2+1=3

→ chmod 763 fichier

Un autre exemple : rw- -w- r-x :
• rw- : 4+2+0=6
• -w- : 0+2+0=2
• r-x : 4+0+1=5

→ chmod 625 fichier

Tu peux lui dire, en lui expliquant clairement à quoi ça te sert, alors qu’il existe une commande chattr et lsattr .
man chattr # change file attributes on a Linux file system
man lsattr # list file attributes on a Linux second extended file system

Tu as oublié de tenir compte
des bits de mode setuid, setgid, et sticky bit qui sont dans le quatrième rang de la valeur octale des 4096 (8⁴) combinaisons possibles de bits de mode qui sont modifiables par la commande chmod


Voir le paragraphe ATTRIBUTS dans le manuel de la commande chattr
en lançant la ligne de commande suivante :

man chattr

Les bits de mode modifiables par la commande chattr et les règles ACL ne font pas partie
des 4096 (8⁴) combinaisons possibles de bits de mode qui sont modifiables par la commande chmod

J’ai oublié quoi ? Je ne fais pas ici un tuto ‹ complet ›, mais juste assez pour démontrer que le sujet est plus subtil que de l’arithmétique approximative de base.
Mais que cherches-tu à part embrouiller un sujet qui n’en demande vraiment pas tant…

»» revoir lehollandaisvolant
→ Forcer l’ID utilisateur
→ Forcer l’ID groupe
Sticky

Rappel de la question initiale: différence entre root et admin
Réponse très simple:

  • root est un "superuser "
  • admin est un groupe dans lequel peuvent être autorisé différents users.

Globalement, la gestion des droits usagers est en fait devenue plus compliquée avec policykit, mais je ne souhaite pas développer ici, alors que la question initiale était très simple, et demandait juste une réponse simple.

PolicyKit concerne l’authentification des comptes utilisateurs
et n’a donc rien à voir avec la gestion des bits de mode d’accès aux fichiers.

Voir le manuel en lançant la ligne de commande suivante :
man polkit


Il ne s’agissait pas du groupe admin mais du groupe adm qui n’a rien à voir avec les privilèges du compte super-utilisateur root

Pour info, le groupe adm est utilisé pour les tâches de surveillance du système. Les membres de ce groupe peuvent lire de nombreux fichiers journaux dans /var/log et peuvent utiliser xconsole. Historiquement, /var/log était /usr/adm (et plus tard /var/adm), d’où le nom du groupe.

Voir : SystemGroups - Debian Wiki

1 J'aime

Lorsqu’un exécutable d’une application peut être exécuté par root, et pas un user, la gestion des droits ne se fait absolument pas en couche basse, on ne va pas trifouiller directement les fichiers système, mais justement au niveau de policykit, en couche haute.
Donc ça n’a pas ‹ rien à voir › avec les droits ‹ root › ou ‹ admin › (la question initiale), et certainement plus que ta liste de 'chmod --verbose g+s aeffacer ’ ou demande de gestion en mode octal des droits.
Ce sera tout pour moi.

bonjour,
( message corrigé )
je me suis mal exprimé : la question que je me pose est quelle différence entre le groupe root et le groupe adm ?

ce group adm est bien dans /etc/group mais il n’apparaît pas dans

mm@Xfce:~$ groups
mm lp cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner
mm@Xfce:~$ sudo groups
[sudo] Mot de passe de mm : 
root

et les réponses que j’ai pu avoir avec le canard ne m’ont pas beaucoup avancé .

ps : je viens de voir le lien donné par MicP :
adm : Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group
serait-ce un genre de root dégradé ? Comment faire apparaître ses membres ?

mm@Xfce:~$ getent group adm
adm:x:4:

cela signifie-t-il qu’il n’y a aucun membre ? même pas root qui pourtant est un administrateur ?

question subsidiaire : comment fait-on pour barrer du texte qu’on veut corriger et le laisser en place ?