Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
Il n'y a pas de compte administrateur dans Debian.
merlin a écrit :Dans le menu de l’interface graphique ‘’Appliczations/Système’’, l’application ‘’Utilisateurs et groupes’’ permet de modifier le type de compte utilisateur
Ce truc est une surcouche graphique, qui sait ce qu'elle fait exactement.
Je pense que tu souffre d’une addiction à la ligne de commande qui altère ton jugement. Ce n’est pas parce que le mot ‘’administrateur’’ n’existe pas dans les fichiers de configuration que le compte administrateur n’existe pas. L’équation est la suivante:
-UID user=0 = utilisateur root = administrateur de type root ;
-UID user≠0 = utilisateur non-root = je ne peux pas administrer !;
-UID user≠0 + sudo = utilisateur de type administrateur non-root = administrateur sudo = je peux administrer !
Si ça peut t’aider, considère le compte admi sudo comme une surcouche conceptuelle.
On sait exactement ce qu’il y a derrière la surcouche graphique : des lignes de commande ! Je pense qu’il faut plonger dans le code source pour avoir le détail.
Exemple : Grsync est l’interface graphique de rsync. Tu choisis les paramètres de la synchronisation via les menus de l’interface graphique. Le programme, dans son retour, t’affiche la ligne de commande qu’il a envoyé au terminal.
Il serait intéressant et pédagogique, que toutes les interfaces graphiques affichent dans une infobulle, la ligne de commande correspondante à chaque entrée des menus.
Pour ce qui est du compte root Unix, l'utilisateur existe toujours avec l'UID 0. Si on ne lui définie pas de mot de passe, on ne peut pas s'y connecter directement, et sudo est alors automatiquement configuré pour pouvoir donner les privilèges root pour toutes les commandes au premier compte utilisateur créé. Ce compte est bien un compte classique et pas administrateur.
Compte classique + sudo = compte administrateur de type sudo = je peux administrer !
Par définition, un administrateur peut administrer tandis qu’un utilisateur simple (NP) ne le peut pas.
Définitions des comptes utilisateurs (version 2)
*compte root=compte système : possède tous les privilèges. Administrateur de type root. Administrateur suprême.
=admi root;
*compte administrateur : utilisateur inscrit au groupe sudo, ce qui lui permet d’accéder au compte root via son mdp personnel. Administrateur de type sudo.
=admi sudo;
*compte utilisateur (simple ou standard)=Non Privilégié. Ne peut pas administrer le système.
=utilisateur NP.
Uilisateur principal : Parfois, le système réclame le mdp de l’utilisateur principal. Selon les cas, ce dernier peut être soit l’administrateur sudo soit l’administrateur root si il n’y a pas d’administrateur sudo.
su : configuration accidentelle. A la différence de sudo, su ne constitue pas un groupe. Ainsi, seul l’admi root, celui qui connaît le mdp root, peut utiliser su pour admininistrer le sytème sous un compte utilisateur NP ou un compte admi sudo. L’utilisateur NP et l’admi sudo ne sont pas supposé connaître le mdp root (réseau entreprise), le contexte étant différent concernant un ordinateur individuel.
Il serait peut-être temps d’en finir avec les approximations et autres confusions.
Qu’en pensez-vous ?
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
Il serait peut-être temps d’en finir avec les approximations et autres confusions.
Qu’en pensez-vous ?
Entièrement d'accord, mais ton dernier message est plein d'approximation 
Compte classique + sudo = compte administrateur de type sudo = je peux administrer !
non, il est tout a fait possible d'installer sudo sans le configurer pour donner les droits root pour toutes blés commandes. Si tu veux t'en convaincre, voici un petit exemple tirer du wiki DF https://debian-facile.org/doc:systeme:sudo#exemple1
Par ailleurs, il existe d'autre mécanismes d'élévation de privilèges, on peut penser à setuid ou policykit.
Donc, à proprement parler, il n'existe pas de compte administrateur (contrairement à Windows aussi loin que je me souvienne) sous Debian, et ce qui s'en rapproche le plus serait le compte root
Ce qui est nommé compte administrateur dans un environnement de bureau est propre à cet environnement, et la.manière obtenir une élévation de privilèges est effectivement écrite dans le code source, et utilisé forcément un mécanisme fourni par Debian.
Donc, les définitions que tu poses là te sont propres. Elles constituent neanmoins une excellente base pour que tout le monde se comprenne dans ton fil 
Attention cependant, elles peuvent poser des problèmes dans certains cas. Il me semble avoir rencontrer un bug avec un mot de passe root défini et sudo configurer un peu comme dans exemple du wiki
Certaines applications graphiques demandaient le mot de passe utilisateur pour obtenir des droits que sudo ne lui donnait pas
Depuis, sur une machine bureautique, c'est soit su soit sudo, mais pas les deux, et le moins possible de logiciels graphiques nécessitant une élévation de privilèges.
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
un compte root est un compte root.
un compte utilisateur est un compte utilisateur.
et un compte admin est un compte admin.
Merçi pour ta collaboration. Il serait dommage pour la communauté de ne pas profiter de ton sens inné de la pédagogie. Pourrait-tu également définir les comptes suivant : superutilisateur, classique, user, simple, standard ?
merlin a écrit :Il serait peut-être temps d’en finir avec les approximations et autres confusions.
Qu’en pensez-vous ?
Entièrement d'accord, mais ton dernier message est plein d'approximation wink
La réalité sur le web et les forums est la suivante : superutilisateur, root, administrateur, utilisateur, classique, user, simple, standard….Ma classification des comptes courants (principaux=ce qui concerne les débutants) me semble constituée une amélioration, même si on pourrait rajouter d’autes catégories ou sous-catégories (pour les experts par exemple). Pourquoi ne propose tu pas ta propre classification, une basique pour les débutants et une complète pour les experts ?
merlin a écrit :Compte classique + sudo = compte administrateur de type sudo = je peux administrer !
non, il est tout a fait possible d'installer sudo sans le configurer pour donner les droits root pour toutes blés commandes. Si tu veux t'en convaincre, voici un petit exemple tirer du wiki DF https://debian-facile.org/doc:systeme:sudo#exemple1 wink
Quelque soit le paramétrage de sudo, l’élévation de privilège passe par sudo. Il s’agit donc dans tous les cas d’un compte de type Administrateur sudo (par opposition à l’Administrateur root et su). Non ?On constate que pour smolski, super-utilisateur est différent de root!
Par ailleurs, il existe d'autre mécanismes d'élévation de privilèges, on peut penser à setuid ou policykit.
Il semble que PolKit (anciennement PolicyKit) permette un gain de sécurité et de confort pour l’utilisateur. Par contre le programme setuid semble présenter des failles de sécurité.
Au final, ces programmes me semblent plutôt indiqués pour des spécialistes ?
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
Dernière modification par smolski (30-08-2019 19:49:27)
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Un utilisateur n'est pas obligatoirement un être humain. La liste des utilisateurs de ta machine devrait t'en convaincre :
cat /etc/passwd
Merci à Philou92. J’ai l’impression que les comptes sont enregistrés dans ce fichier /etc/passwd dans l’ordre chronologique de leur création.
En effet, il est important de savoir qui utilise la machine. On peut donc distinguer les utilisateurs humains et les utilisateurs de type programme. Ces derniers peuvent être classés en deux catégories, les utilisateurs de type système qui travaillent pour le système et les utilisateurs de type application qui sont des programmes travaillant pour les applications personnelles que l’on a introduit après l’installation du système.
Je pense qu’une application qui utilise la connection réseau Internet, y compris une frauduleuse, doit obligatoirement avoir un compte (avec les privilèges nécessaires) dans ce registre /etc/passwd, afin de pouvoir passer le pare-feu. D’où l’importance de contrôler l’authenticité de chaque compte.
Dès qu’on auras définit clairement les comptes utilisateurs humains, alors on pourra s’intéresser aux utilisateurs de type programme.
On constate que pour smolski, super-utilisateur est différent de root!
Je faisais référence au wiki DF (intitulé ‘’sudo’’) indiqué par le lien fournis par bendia#28. Ce wiki crée par smolski date du 27/11/2012. Voici le paragraphe concerné :
Root est unanimement considéré comme le super-utilisateur. Pourtant smolski mentionne un superutilisateur qui n’est pas root !? En effet, il peut y avoir plusieurs super-utilisateurs. Root est le super-utilisateur par défaut, il fait partie du groupe des super-utilisateurs, dont le nom est root. Il est donc possible de créer d’autres comptes de type super-utilisateur, j’imagine, en rattachant un compte au groupe root ?
Cette page web relate une discussion détaillée sur le thème ‘’super-utilisateur vs root’’ et aussi sur la signification et le fonctionnement de su et sudo:
https://superuser.com/questions/1438817 … me-as-root
Bon superutilisateur a un tuto :
https://debian-facile.org/doc:systeme:superutilisateur
destiné aux débutants plus qu'aux plus avisés.
Si ce qu'il contient n'est pas assez clair, tous les membres df peuvent intervenir dan sle tuto pour l'améliorer et indiquer dans le lien vers le forum du tuto ce qu'ils ont fait, pour une meilleure gestion communautaire du wiki.
À vos plumes et suggestions ! big_smile
Ce tuto est parfaitement claire, trop claire pour être réaliste, surtout quand on vient de lire la discussion sus-citée publiée sur superuser.com.
Ce tuto intitulé ‘’Root’’ publié le 11/06/13 nous apprend que root=administrateur=super-utilisateur. Ce n’est plus la même version que dans celui intitulé ‘’sudo’’ où super-utilisateur est différent de root. Pourtant, les deux tuttos concernent un public débutant et avisé.
Définitions des comptes utilisateurs (version 3)
*compte administrateur root=compte système : possède tous les privilèges. Administrateur de type root. Super-utilisateur par défaut, appartient au groupe root.
*compte super-utilisateur non-root : utilisateur inscrit au groupe root ?
*compte administrateur sudo : utilisateur inscrit au groupe sudo, ce qui lui permet d’accéder au compte root via son mdp personnel. Administrateur de type sudo ;
*compte utilisateur NP (Non Privilégié): Utilisateur standard ou simple. Ne peut pas administrer le système, car il ne connaît pas le mdp root et n’est pas inscrit au groupe sudo ni au groupe root.
Uilisateur principal : Parfois, le système réclame le mdp de l’utilisateur principal. Selon les cas, ce dernier peut être soit l’administrateur sudo soit l’administrateur root si il n’y a pas d’administrateur sudo.
su et sudo
A la différence de sudo, su ne constitue pas un groupe. Ainsi, seul l’admi root, celui qui connaît le mdp root, peut utiliser su pour admininistrer le sytème sous un compte utilisateur NP ou un compte admi sudo. L’utilisateur NP et l’admi sudo ne sont pas supposé connaître le mdp root (réseau entreprise), le contexte étant différent concernant un ordinateur individuel.
Il est posible de configurer sudo pour fonctionner comme su et vice-versa.
Pour comprendre l’intérêt de chaque type de compte utilisateur, notamment en matère de sécurité, il est indispensable de comprendre la signification et le fonctionnement de su et sudo, puisque ces deux programmes contrôlent l’accès aux privilèges root, sinon il est impossible d’avoir un système sécurisé.
J’invite tous les membres concernés par la sécurité de leur système à digérer ces informations et à proposer une classification des comptes utilisateurs en relation avec la configuration de su et sudo.
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
melissa6969 a écrit :un compte root est un compte root.
un compte utilisateur est un compte utilisateur.
et un compte admin est un compte admin.
Merçi pour ta collaboration. Il serait dommage pour la communauté de ne pas profiter de ton sens inné de la pédagogie. Pourrait-tu également définir les comptes suivant : superutilisateur, classique, user, simple, standard ?
[modéré]
PS 2 :
ça n'existe plus depuis Buster.....
c'est
ça serait bien de pas donner de fausses infos...
Dernière modification par melissa6969 (10-09-2019 21:54:00)
Quamdiu est spes est, Est vitae.
Fiet in posterum melius
Hors ligne
Hors ligne
Merci à Philou92. J’ai l’impression que les comptes sont enregistrés dans ce fichier /etc/passwd dans l’ordre chronologique de leur création.
En effet, il est important de savoir qui utilise la machine. On peut donc distinguer les utilisateurs humains et les utilisateurs de type programme.
En fait, le « type » d'utilisateur est plus une convention. Les utilisateurs système ont un ID < 1000, n'autorisent pas de connexion par mot de passe, ils ont souvent un répertoire HOME personnalisé (voire pas de HOME), un shell personnalisé (voire un shell désactivé), et peuvent appartenir à un groupe spécial comme nogroup. De plus, les utilisateurs humains appartiennent par défaut à certains groupes (cdrom, …).
Ceci dit, il est tout à fait possible de se loguer en tant qu'un de ces utilisateurs système, par exemple avec
ou de lancer un programme en tant qu'utilisateur humain (c'est ce qui arrive à chaque fois que tu lances firefox).
Ces derniers peuvent être classés en deux catégories, les utilisateurs de type système qui travaillent pour le système et les utilisateurs de type application qui sont des programmes travaillant pour les applications personnelles que l’on a introduit après l’installation du système.
Disons que certains sont déjà présent par convention (root, bin, daemon, …), d'autres sont introduits par la distribution (groupe adm), et d'autres sont amenés par l'installation de paquets (sshd, …).
Je pense qu’une application qui utilise la connection réseau Internet, y compris une frauduleuse, doit obligatoirement avoir un compte (avec les privilèges nécessaires) dans ce registre /etc/passwd, afin de pouvoir passer le pare-feu.
Un programme est tout le temps attribué à un utilisateur. Tous les utilisateurs ont le droit d'accéder au réseau s'il est en place. Mais pas tous ont le droit d'établir une connexion et de configurer le réseau. Ceci nécessite des privilèges, qui peuvent être délégués, ou actionnés via dbus (un daemon tourne avec ces privilèges et écoute sur le dbus, un programme utilisateur envoie une requête dbus au premier…)
Dès qu’on auras définit clairement les comptes utilisateurs humains, alors on pourra s’intéresser aux utilisateurs de type programme.
Comme je l'ai dit, la notion de compte « humain » n'est qu'un ensemble de paramètres par défaut, une fois le compte créé, c'est un compte, et puis c'est tout.
On constate que pour smolski, super-utilisateur est différent de root!
« root » est le nom d'utilisateur du super-utilisateur, c'est à dire de l'utilisateur d'ID 0.
Il n'y a qu'un seul super-utilisateur, c'est root. Il est possible mais très fortement déconseillé, d'ajouter d'autres utilisateurs au groupe root. Cela ne fera pas d'eux des super-utilisateurs, ils pourront simplement modifier/lire/exécuter les fichiers qui n'étaient modifiable/lisible/exécutable seulement par le groupe root.
Cependant, root peut déléguer ses droits en utilisant l'utilitaire sudo.
sudo permet à des utilisateurs vérifiant un certain nombre de règles personnalisables de lancer avec des droits personnalisés des commandes parmi un ensemble de commandes personnalisés.
La délégation la plus fréquente est d'autoriser les utilisateurs appartenant au groupe « sudo » de lancer avec les droits root n'importe quelle commande sur le système avec leur propre mot de passe.
Mais on peut tout à fait déléguer à l'utilisateur tartempion le droit d'exécuter en tant que geronimo la commande /bin/false sans saisir aucun mot de passe.
Je te renvois au manuel de sudo pour plus de détails (bien qu'il ne soit pas forcément très simple à lire).
Définitions des comptes utilisateurs (version 3)
*compte administrateur root=compte système : possède tous les privilèges. Administrateur de type root. Super-utilisateur par défaut, appartient au groupe root.
*compte super-utilisateur non-root : utilisateur inscrit au groupe root ?
*compte administrateur sudo : utilisateur inscrit au groupe sudo, ce qui lui permet d’accéder au compte root via son mdp personnel. Administrateur de type sudo ;
*compte utilisateur NP (Non Privilégié): Utilisateur standard ou simple. Ne peut pas administrer le système, car il ne connaît pas le mdp root et n’est pas inscrit au groupe sudo ni au groupe root.
Uilisateur principal : Parfois, le système réclame le mdp de l’utilisateur principal. Selon les cas, ce dernier peut être soit l’administrateur sudo soit l’administrateur root si il n’y a pas d’administrateur sudo.
Il ne faut pas mélanger les appelations sémantiques à géométrie variable et les termes techniques.
« administrateurs », c'est un terme sémantique qui désigne une personne gérant la machine. Il peut y avoir différents niveaux d' « administrateur ». Si tu veux parler du compte super-utilisateur, utilises de préférence la terminologie « compte root » ou « compte super-utilisateur ».
En effet, il existe par exemple le groupe « adm » qui permet aux personnes « administrant la machine » de, sans être root, accéder aux logs système.
En ce qui concerne les privilèges, il faut distinguer les privilèges que sont les droits du super-utilisateur, et les privilèges qui peuvent être « délégués » par sudo, su, ou d'autres programmes.
Donc, pour résumé, il y a deux types de comptes utilisateurs réellement distincts :
le compte utilisateur root
les comptes utilisateurs non-root
Un compte utilisateur peut se voir déléguer des privilèges via sudo, en fonction de son nom d'utilisateur ou de son groupe.
La dénomination « compte utilisateur principal » vient de ce que l'installateur, lorsque le mot de passe root est désactivé, ajoute automatiquement le premier utilisateur créé lors de l'installation dans le groupe sudo, ce qui, via la délégation sudo, lui permet de « passer root » et exécuter n'importe quelle application en tant que root.
su et sudo
A la différence de sudo, su ne constitue pas un groupe. Ainsi, seul l’admi root, celui qui connaît le mdp root, peut utiliser su pour admininistrer le sytème sous un compte utilisateur NP ou un compte admi sudo. L’utilisateur NP et l’admi sudo ne sont pas supposé connaître le mdp root (réseau entreprise), le contexte étant différent concernant un ordinateur individuel.
Il est posible de configurer sudo pour fonctionner comme su et vice-versa.
su permet de se logguer temporairement en tant qu'un utilisateur lambda, notamment root, et demande pour se faire le mot de passe de l'utilisateur, sauf si l'utilisateur lançant su est root. La seule « délégation » est de donner à la personne connaissant le nom d'utilisateur et le mot de passe d'un utilisateur, les droits de cet utilisateur. Par exemple, les droits root si l'utilisateur connaît le mdp root.
sudo est un mécanisme de délégation plus fin, comme indiqué plus haut. Il ne faut pas confondre l'application sudo et le groupe sudo. Le groupe sudo n'est créé par défaut avec la délégation associée que par convention, et ils peuvent être supprimés/renommés/etc.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
« root » est le nom d'utilisateur du super-utilisateur, c'est à dire de l'utilisateur d'ID 0.
Il n'y a qu'un seul super-utilisateur, c'est root.
En fait on peut créer d'autres utilisateurs avec l'UID 0, qui auront donc les mêmes privilèges que root.
Il vaut mieux montrer que raconter.
Hors ligne
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
Dernière modification par raleur (11-09-2019 17:02:13)
Il vaut mieux montrer que raconter.
Hors ligne
Chacun a son propre identifiant, mot de passe, répertoire personnel, interpréteur de commande...
Tu peux créer en parallèle sur le même système un utilisateur avec un uid déjà utilisé ? Ou je comprend mal, et ça revient à changer le nom de l'utilisateur root et d'autres variables comme le /home ou le shell ?
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
et ça roule.
Ben
___________________
La seule question bête, c'est celle qu'on ne pose pas.
Hors ligne
On peut donc distinguer les utilisateurs humains et les utilisateurs de type programme. Ces derniers peuvent être classés en deux catégories, les utilisateurs de type système qui travaillent pour le système et les utilisateurs de type application qui sont des programmes travaillant pour les applications personnelles que l’on a introduit après l’installation du système.
Je me suis mal exprimé concernant les deux catégories d'utilisateurs de type "programme", je voulais distinguer les programmes de type "système" qui sont non interactifs et qui travaillent en arrière-plan des programmes de type "application" qui sont interactifs et sont activé par l'utilisateur humain.
Tous les utilisateurs ont le droit d'accéder au réseau s'il est en place. Mais pas tous ont le droit d'établir une connexion et de configurer le réseau.
Il me semble que tu te contredis. Tu oppose ‘’accéder au réseau ‘’ et ‘’établir une connexion’’ !? Pour moi, ces deux expressions sont synonymes. Non ?
En effet, il existe par exemple le groupe « adm » qui permet aux personnes « administrant la machine » de, sans être root, accéder aux logs système.
Le groupe adm ne donne aucun pouvoir de modifier (=administrer) le système, son importance est donc marginale par rapport au groupe sudo qui est le seul a donner un pouvoir d’administration.On ne va pas créer un type de compte pour chaque groupe (audio, vidéo, bluetooth,…..etc). Mon but est de décire et de comprendre les types de compte utilisateur proposés par le système Debian. Après, il est évident que les deux comptes non-root (administrateur sudo et utilisateur NP) peuvent être personnalisés en les rattachant ou non à d’autres groupes.
Donc, pour résumé, il y a deux types de comptes utilisateurs réellement distincts :
le compte utilisateur root
les comptes utilisateurs non-root
Cela revient à dire que le compte admi sudo n’est pas réel et à le mettre dans le même sac que le compte utilisateur NP !
Il est indéniable que le compte root se distingue des comptes non-root. Cependant, là où je ne suis pas daccord, c’est que tu ne veux pas qualifier d’administrateur le compte utilisateur qui est rattaché au groupe sudo, ce que fait pourtant l’interface graphique (Menu/administration/Utilisateurs et Groupes). Même si le compte utilisateur qui est rattaché au groupe sudo n’est qu’un délégataire de root, il a le pouvoir de modifier le système, ce qui fait de lui, sans aucun doute possible, un administrateur. Mais sachant que root est aussi un administrateur, il est logique de distinguer les deux en qualifiant d’administrateur sudo le compte utilisateur qui est rattaché au groupe sudo.
Peux-tu décrire ce que tu appelle les comptes utilisateurs non-root ?
merlin a écrit :su et sudo
A la différence de sudo, su ne constitue pas un groupe. Ainsi, seul l’admi root, celui qui connaît le mdp root, peut utiliser su pour admininistrer le sytème sous un compte utilisateur NP ou un compte admi sudo. L’utilisateur NP et l’admi sudo ne sont pas supposé connaître le mdp root (réseau entreprise), le contexte étant différent concernant un ordinateur individuel.
Il est posible de configurer sudo pour fonctionner comme su et vice-versa.
su permet de se logguer temporairement en tant qu'un utilisateur lambda, notamment root, et demande pour se faire le mot de passe de l'utilisateur, sauf si l'utilisateur lançant su est root. La seule « délégation » est de donner à la personne connaissant le nom d'utilisateur et le mot de passe d'un utilisateur, les droits de cet utilisateur. Par exemple, les droits root si l'utilisateur connaît le mdp root.
sudo est un mécanisme de délégation plus fin, comme indiqué plus haut. Il ne faut pas confondre l'application sudo et le groupe sudo. Le groupe sudo n'est créé par défaut avec la délégation associée que par convention, et ils peuvent être supprimés/renommés/etc.
Dans mon paragraphe ‘’su et sudo’’ je ne parle pas de délégation et je ne confond pas, concernant sudo, le programme et le groupe. Je constatais simplement que l’accès à root via su ne s’obtient pas par inscription à un groupe, comme pour sudo, et donc que seul le détenteur du mdp root peut utiliser su.
Si tu pense que ce paragraphe contient des erreurs, ce serait plus simple d’indiquer précisément quel est le mot, l’expression ou la phrase concernée.
captnfab a écrit :« root » est le nom d'utilisateur du super-utilisateur, c'est à dire de l'utilisateur d'ID 0.
Il n'y a qu'un seul super-utilisateur, c'est root.
En fait on peut créer d'autres utilisateurs avec l'UID 0, qui auront donc les mêmes privilèges que root.
J'ai bien failli croire que le site superuser.com, c'était de l'intox. Ceci dit, je n’ai pas trouvé d’autres sites concernant cette possibilité de créer d’autres super-utilisateurs. Pourquoi cette fonctionnalité est-elle si confidentielle ? Il semble risqué de laisser le contrôle d’un système à un seul super-utilisateur, car un administrateur sudo n’est qu’un délégataire du super-utilisateur, il ne dispose pas de l’environnement root complet.
Est-ce que tous les super-utilisateurs d'un système auront exactement le même pouvoir ou bien le super-utilisateur par défaut (root) garde-t-il un avantage? Autrement dit, est-ce que le nouveau super-utilisateur peut éliminer root?
Reste à décider si deux utilisateurs avec le même UID sont des utilisateurs différents ou non
Un UID ayant pour valeur 0 n’a peût-être pas la même signification qu’un UID ayant une valeur plus ‘’logique individuelle’’comme 1, 12 ou 1000.
Il est possible que cet identifiant UID=0 soit plutôt à considérer comme une catégorie ou même un groupe. UID=0=groupe des utilisateurs de type super. Ce serait donc un concept à géométrie variable.
Ça dépend comment on regarde. Chacun a son propre identifiant, mot de passe, répertoire personnel, interpréteur de commande... C'est pour cette raison qu'il m'est arrivé de créer un tel compte superutilisateur.
Par contre les processus lancés par l'un ou par l'autre ou le propriétaire des fichiers sont indiscernables puisqu'ils ont le même UID 0.
Pourquoi le nom de l'utilisateur n’est pas enregistré conjointement avec l'UID dans les journaux et le registre de propriété ? Y-aurait-il moyen de modifier cette configuration?
Ah, j'aimerais bien connaître la manip, je viens d'essayer avec un truc du genre adduser --uid 0 toto, et ça n'abouti pas parce-que l'UID 0 est déjà utilisé.
Il me semble que pour certaines commandes, un refus d’exécution constitue simlement un avertissement invitant l’utilisateur à réfléchir. N’y-a-t-il pas moyen de passer outre, de forcer l‘exécution ?
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
Il me semble que tu te contredis. Tu oppose ‘’accéder au réseau ‘’ et ‘’établir une connexion’’ !? Pour moi, ces deux expressions sont synonymes. Non ?
Non : accéder au réseau, c'est communiquer en utilisant une connexion réseau établie (au sens de liaison, pas au sens de connexion TCP qui n'est qu'une communication). Etablir une connexion réseau c'est activer et configure l'interface, ce qui nécessite des privilèges. C'est la même distinction qu'entre "accéder au contenu d'un système de fichiers monté" (modulo les permissions) et "monter un système de fichiers" (qui nécessite des privilèges).
Ceci dit, je n’ai pas trouvé d’autres sites concernant cette possibilité de créer d’autres super-utilisateurs. Pourquoi cette fonctionnalité est-elle si confidentielle ?
Elle n'est pas confidentielle, elle est inhérente à la notion d'UID.
Il semble risqué de laisser le contrôle d’un système à un seul super-utilisateur, car un administrateur sudo n’est qu’un délégataire du super-utilisateur, il ne dispose pas de l’environnement root complet.
Je ne vois pas le rapport. En quoi est-ce risqué ?
Est-ce que tous les super-utilisateurs d'un système auront exactement le même pouvoir
Oui. C'est inhérent à l'UID 0 qui est traité de façon spéciale : il a tous les privilèges et les permissions ne s'appliquent pas.
Pourquoi le nom de l'utilisateur n’est pas enregistré conjointement avec l'UID dans les journaux et le registre de propriété ?
Quels journaux ?
J'ignore ce qu'est le "registre de propriété".
Il vaut mieux montrer que raconter.
Hors ligne
Je me suis mal exprimé concernant les deux catégories d'utilisateurs de type "programme", je voulais distinguer les programmes de type "système" qui sont non interactifs et qui travaillent en arrière-plan des programmes de type "application" qui sont interactifs et sont activé par l'utilisateur humain.
Sauf que… il n'y a aucune différence au niveau du compte. Seulement sur la manière dont il est utilisé.
Qui plus est, pour qu'un utilisateur X lance un programme en tant que Y, il faut qu'il y ait un système de délégation, souvent un bit d'exécution setuid, ou un mécanisme client/serveur/authentification à la dbus.
Le groupe adm ne donne aucun pouvoir de modifier (=administrer) le système, son importance est donc marginale […]. Mon but est de décire et de comprendre les types de compte utilisateur proposés par le système Debian. […]
Tu confonds les « types » d'utilisateurs/groupes et leurs rôles. Le type est une propriété formelle, appartenant au modèle, le rôle est une interprétation plus ou moins subjective. Le groupe adm et le groupe sudo sont du même type, ce sont des groupes, sans mot de passe.
Leur fonctions sont différentes, mais ça n'a aucun rapport avec le « type » de compte.
Donc, pour résumé, il y a deux types de comptes utilisateurs réellement distincts :
le compte utilisateur root
les comptes utilisateurs non-root
Cela revient à dire que le compte admi sudo n’est pas réel et à le mettre dans le même sac que le compte utilisateur NP !
Tout à fait, et c'est complètement le cas.
Il est indéniable que le compte root se distingue des comptes non-root. Cependant, là où je ne suis pas daccord, c’est que tu ne veux pas qualifier d’administrateur le compte utilisateur qui est rattaché au groupe sudo[…]
Alors, que tu sois d'accord où non ce n'est pas mon problème. Comme je te l'ai dit, les appellations « compte administrateur » sont subjectives, contextuelles, etc. Donc, c'est un mauvais choix que d'utiliser ces définitions là.
Par contre, tu peux dire tout simplement que le compte root, et les comptes pouvant obtenir les privilèges root via sudo (par exemple via le groupe sudo si le fichier sudoer est configuré pour donner les pleins pouvoirs à ce groupe, ce qui n'est pas toujours le cas) ont la possibilité d'administrer le système. Là, tu ne dis pas de bêtise et tu n'imposes pas tes définitions.
Peux-tu décrire ce que tu appelle les comptes utilisateurs non-root ?
Tous les comptes utilisateurs dont l'uid n'est pas 0.
Dans mon paragraphe ‘’su et sudo’’ je ne parle pas de délégation et je ne confond pas, concernant sudo, le programme et le groupe. Je constatais simplement que l’accès à root via su ne s’obtient pas par inscription à un groupe, comme pour sudo, et donc que seul le détenteur du mdp root peut utiliser su.
Si tu pense que ce paragraphe contient des erreurs, ce serait plus simple d’indiquer précisément quel est le mot, l’expression ou la phrase concernée.
Pardon mais, pour moi, ta phrase n'a pas de sens. sudo ne constitue pas un groupe. La configuration par défaut du programme sudo crée un groupe homonype et lui délègue des droits. Ceci n'est qu'une configuration par défaut. sudo fonctionne très bien sans groupe sudo. Inversement, su n'est pas utilisable seulement avec le mot de passe root. su utilises PAM pour l'authentification et dispose donc de tous les mécanismes d'authentifications inhérents. Il est vastement configurable. La configuration par défaut demande le mot de passe du compte utilisateur auquel on veut se connecter (pas forcément root donc).
J'ai bien failli croire que le site superuser.com, c'était de l'intox. Ceci dit, je n’ai pas trouvé d’autres sites concernant cette possibilité de créer d’autres super-utilisateurs. Pourquoi cette fonctionnalité est-elle si confidentielle ? Il semble risqué de laisser le contrôle d’un système à un seul super-utilisateur, car un administrateur sudo n’est qu’un délégataire du super-utilisateur, il ne dispose pas de l’environnement root complet.
Est-ce que tous les super-utilisateurs d'un système auront exactement le même pouvoir ou bien le super-utilisateur par défaut (root) garde-t-il un avantage? Autrement dit, est-ce que le nouveau super-utilisateur peut éliminer root?
De mon point de vue, créer deux logins avec même UID, ça reste créer un seul utilisateur avec deux moyens de se connecter, deux HOME, deux SHELL… Mais un seul compte derrière.
Ça reste « confidentiel » parce que c'est bien souvent inutile.
Pour ce qui est de la suppression de compte, le super-utilisateur peut supprimer n'importe quel compte, même le sien, c'est juste une ligne à enlever dans un fichier.
Entre parenthèse, tu peux très bien donner un fichier à un utilisateur qui n'existe pas.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne
su
ça n'existe plus depuis Buster.....
c'est
su -
ça serait bien de pas donner de fausses infos...
Sous Buster la page man de su est datée de Juillet 2014 !
Quand on critique, on est supposé 1) apporter la preuve de l'erreur et 2) donner des arguments compréhensibles et sérieux.
1/Ce serait bien que tu indiques le numéro (#) du message qui serait concerné par cette fausse infos.
2/En général, et ça ne date pas d’hier, le tiret sert à introduire une option. Cependant, tu peux utiliser su sans option. Par exemple, sous Buster:
merlin@debian:~$ su
Mot de passe :
root@debian:/home/merlin#
merlin a écrit :
Il semble risqué de laisser le contrôle d’un système à un seul super-utilisateur, car un administrateur sudo n’est qu’un délégataire du super-utilisateur, il ne dispose pas de l’environnement root complet.
Je ne vois pas le rapport. En quoi est-ce risqué ?
Je ne suis pas sûr de comprendre pour le rapport, mais je voulais dire que si l’unique administrateur root est compromis, par exemple parce que son mdp root lui a été extorqué, aolrs le système (et ses données) est condamné. Tandis que si il y a plusieurs super-utilisateurs, alors ceux qui ne sont pas compromis peuvent avoir une chance de réagir avant ou pendant l’attaque (intrusion). C’est pendant l’attaque, je pense, que la différence de privilèges entre un admi sudo et un super-utilisateur se fera sentir.
merlin a écrit :
Pourquoi le nom de l'utilisateur n’est pas enregistré conjointement avec l'UID dans les journaux et le registre de propriété ?
Quels journaux ?
J'ignore ce qu'est le "registre de propriété".
Je m’intéresse à tous les journaux (système, utilisateurs,…..) qui permettent de vérifier ‘’qui fait quoi’’ avec le système, que ce soit via les privilèges ou les permissions. Par registre de propriété, je voulais dire ‘’le journal qui consigne les accès aux fichiers’’.
Linux étant hautement configurable, il doit bien y avoir moyen de configurer les programmes dédiés pour qu’ils enregistrent, dans les journaux, l’identification complète (UID + nom d’utilisateur) des utilisateurs.
Définitions des comptes utilisateurs humains (version 4)
Ce tuto destiné aux débutants (y compris moi-même) est en cours d’élaboration, les critiques argumentées et compréhensibles sont les bienvenues
A/Introduction
La classification que je propose est basée sur la configuration par défaut du système Debian, c’est à dire sur les types de compte proposés lors de l’installation.
Le système Debian propose, par défaut , trois type de compte , qui sont caractérisés chacun par leur capacité à accéder ou non, aux privilèges-root et à certains privilèges-utilisateur. Les privilèges de chaque compte sont déterminés par la valeur de leur UID (User IDentifier) et les groupes auquels le compte est rattaché. Chaque groupe est identifié par une valeur intitulée GID ( Group IDentifier). On obtient les identifiants (UID et GID) d'un compte avec la commande ‘’id’’ suivie du nom d'utilisateur. Le retour type du terminal est le suivant: UID, GID (groupe primaire) et groupes (GID des groupes secondaires).
Il y a d’autres manières pour un utilisateur d’obtenir une élévation de privilèges , mais ces configurations sont plutôt réservées aux spécialistes et ne concernent donc pas le débutant.
Pour comprendre l’intérêt de chaque type de compte, il ne pas oublier que Debian est un système multi-utilisateurs conçu pour l’entreprise.
Dans ce cas de figure, l’ utilisateur NP et l’ admi sudo ne sont pas supposé connaître le mdp root. Cette configuration d’entreprise peut également s’appliquer à un ordinateur familial, pour lequel on peut compartimenter via les différents comptes, les privilèges et les permissions. Par contre, le contexte est différent concernant un ordinateur individuel, le propriétaire étant à la fois utilisateur et administrateur.
B/La configuration par défaut : trois types de compte
Le compte root (appelation GUI et CLI)=administrateur root=super-utilisateur : uid=0(root) gid=0(root) groupes=0(root)
C'est le premier compte créé lors de l'installation, il est demandé de choisir un mdp.Il possède tous les privilèges grâce à son UID=0, c’est à dire que les permissions ne s’appliquent pas. Root est le nom du super-utilisateur par défaut, il est possible de créér d'autres super-utilisateurs, ayant le même UID et GID, mais avec un nom et un mdp différents. C’est-à-dire que plusieurs super-utilisateurs utilisent le même compte.Le compte administrateur sudo=administrateur (appelation GUI) :
uid=1000(merlin-sudo) gid=1000(merlin-sudo) groupes=1000(merlin-sudo), 24(cdrom), 25(floppy), 27(sudo), 29(audio), 30(dip), 44(video), 46(plugdev), 109(netdev), 111(bluetooth), 116(lpadmin), 117(scanner).
Ce compte est créé par défaut lors de l'installation si le mdp root est désactivé, c'est à dire non-définit. Il s’agit d’un compte administrateur non-root.
Cet utilisateur est inscrit au groupe sudo, ce qui lui permet d’accéder au compte root via son mdp personnel. Par défaut, il est également rattaché aux groupes secondaires sus-cités, ce qui lui donne les privilèges correspondants;Le compte utilisateur NP (Non Privilégié)=Utilisateur standard (appelation GUI) : uid=1001(merlin-np) gid=1001(merlin-np) groupes=1001(merlin-np).
Ce compte est crée par défaut lors de l'installation si le mdp root est activé c'est à dire définit. Ne peut pas administrer le système, car il ne connaît pas le mdp root et n’est pas inscrit au groupe sudo. Par défaut, ce compte n'est inscrit à aucun groupe secondaire, il ne pourra donc pas utiliser certains programmes (audio, vidéo,....).
L’uilisateur principal : Ce n’est pas un compte particulier. Parfois, le système réclame le mdp de l’utilisateur principal, c'est à dire de l’utilisateur qui peut administrer. Selon les cas, ce dernier peut être soit l’administrateur sudo soit l’administrateur root si il n’y a pas d’administrateur sudo.
C/Les groupes notables : sudo et root
Le groupe sudo est le seul groupe dont le rattachement à un compte permet l’acquisition des privilèges root pour ce compte.
L’inscription au groupe root permet d’obtenir toutes les permissions d’accès aux fichiers, puisque qu’on peut lire, écrire ou exécuter sur l’ensemble des fichiers utilisateurs
Les deux comptes non-root (admi sudo et utilisateur NP) peuvent être personnalisés, l'inscription à un nouveau groupe permet d'obtenir un nouveau privilège. Par exemple, si l'admi sudo s'inscrit au groupe adm, il pourra consulter les journaux systèmes et les journaux utilisateurs. Egalement, si l'utilisateur NP est inscrit au groupe vidéo, par un administrateur (sudo ou root), il pourra regarder des vidéos.
D/Les programmes su et sudo
Pour comprendre l’intérêt de chaque type de compte utilisateur, notamment en matère de sécurité, il est indispensable de comprendre la signification et le fonctionnement de su et sudo, puisque ces deux programmes, toujours dans le cadre de la configuration par défaut, contrôlent l’accès aux privilèges root.
su = substitute user = switch user to = fermer le compte actif et basculer sur le compte de l’utilisateur xxxx.
Si aucun argument n'est indiqué, alors la commande s'exécute pour l'utilisateur par défaut qui est root et réclame donc le mdp root. On obtient donc le terminal root, c'est à dire une ouverture permanente des privilèges root. Il est donc fortement déconseillé de se connecter à internet ou de laisser son ordinateur sans surveillance.
A la différence de sudo, su ne constitue pas un groupe. Ainsi, seul l’admi root, celui qui connaît le mdp root, peut utiliser su pour admininistrer le sytème sous un compte utilisateur NP ou un compte admi sudo.
sudo = su + do = swith user to root and do
Ici encore, l'utilisateur par défaut est root. Sudo est un utilitaire qui permet de sécuriser l'accès à root en paramétrant la durée d'ouverture des privilèges root, et ceci sans basculer dans le terminal root. Par exemple, avec timeout=0, l'ouverture des privilèges est valable uniquement pour une commande. Il faudra donc saisir son mdp à chaque commande (idéal pour administrer connecté à Internet). On peut aussi régler timeout pour une durée déterminée (10 minutes par exemple) ou pour une durée infini (pour administrer hors-réseau bien sûr). Par défaut, timeout est réglé à xx minutes ?
………………………….Questions à résoudre………………..
Il est posible de configurer sudo pour fonctionner comme su (sudo -i) et vice-versa (su -c), mais alors, pourquoi dit-on que sudo est plus sécurisé que su?
Est-ce que su -c est moins sécurisé que sudo avec timeout=0 ?
Je pense qu’il peut être intéressant en matière de sécurité qu’il y ait plusieurs super-utilisateurs sur un système. Mais comment fait-on pour créer ‘’proprement’’ un nouveau super-utilisateur, c’est à dire avec un environement complet (similaire à celui de root) et donc avec tous les liens que cela implique ?
Quelle est la syntaxe de la commande adduser pour la création de chaque type de compte ?
…………...Pourquoi le référencement-Google de cette discussion est il si mauvais ?………...
Avec Qwant et Duckduckgo il suffit de saisir trois mots-clès (comptes-utilisateurs-définitions) pour obtenir l’affichage du lien vers cette discussion en début de première page.
Avec Google , il faut saisir quatres mots (comptes-utilisateurs-définitions-confusions) pour obtenir l’affichage du lien vers cette discussion en fin de première page. Sachant que le mot ‘’confusions’’ n’a aucune valeur de mot-clè, puisque personne ne l’utilisera dans une recherche concernant les comptes utilisateurs, cela signifie que sur Google cette discussion est invisible.
Concernant une autre discussion, également relative aux comptes utilisateurs, intitulée '’Faut-il créer un compte administrateur et définir un mdp root ?’’, il faut saisir 7 mots (compte-administrateur-mot-passe-root-créer-définire) pour obtenir un lien avec Google. Si on oubli, le ‘’e’’ à la fin de ‘’définir’’, faute qui n’existe pas dans le titre, alors l’expression ‘compte administrateur mot passe root créer définir’ ne donne aucun résultat.
Par contre, toujours avec Google, ma discussion intitulée '’[Résolu]zuluCrypt : Comment monter un volume veracrypt ?’’ est parfaitement référencée et donc visible.
Est-ce un problème du côté de Debian-Facile ou de Google ?
Dernière modification par merlin (19-09-2019 21:23:51)
Processeur Intel Core i5-3320M-2,6 GHz.
Hors ligne
Je ne suis pas sûr de comprendre pour le rapport, mais je voulais dire que si l’unique administrateur root est compromis, par exemple parce que son mdp root lui a été extorqué, aolrs le système (et ses données) est condamné. Tandis que si il y a plusieurs super-utilisateurs, alors ceux qui ne sont pas compromis peuvent avoir une chance de réagir avant ou pendant l’attaque (intrusion). C’est pendant l’attaque, je pense, que la différence de privilèges entre un admi sudo et un super-utilisateur se fera sentir.
Non, au contraire.
Une fois qu'un attaquant a pu se connecter en tant que root à un système, celui-ci est compromis et ne doit plus être utilisé. Il doit être éteint et accédé à partir d'une autre installation sûre (auquel cas, il suffit d'être administrateur sur celle-ci).
Ajouter un autre compte root, c'est une autre porte d'entrée pour un attaquant. Ça n'apporte aucune sécurité.
Je m’intéresse à tous les journaux (système, utilisateurs,…..) qui permettent de vérifier ‘’qui fait quoi’’ avec le système, que ce soit via les privilèges ou les permissions. Par registre de propriété, je voulais dire ‘’le journal qui consigne les accès aux fichiers’’.
Par défaut, il n'existe pas de tels fichiers, en général. Et heureusement, car chaque accès à ce fichier devrait être loggué, et consisterait donc un nouvel accès au fichier
La classification que je propose est basée sur la configuration par défaut du système Debian, c’est à dire sur les types de compte proposés lors de l’installation.
Ce qui est louable. Mais en l'état actuel, elle me pose un problème, parce qu'elle ne suit pas d'assez près le fonctionnement du système. Elle devient fausse quand on personnalise son système, ce qui indique qu'elle donne une intuition fausse de la manière dont les choses fonctionnent sous le capot.
Elle tente de répondre à un besoin de repères de la part de l'utilisateur qui débarque, ou de celui qui n'a pas trop creusé le sujet. En soit, il est donc légitime et même bienvenu de tenter une telle classification. Mais alors, il faut à tout prix éviter d'introduire un nouveau vocabulaire qui ne colle pas avec celui du système, ou, d'utiliser celui du système pour lui faire dire autre chose.
Qui plus est, « sudo » n'est pas le seul mécanisme permettant de déléguer des droits. Polkit gagne du terrain sur ce plan. Polkit considère comme « administrateurs » (au sens de polkit) l'utilisateur root et les membres du groupe « sudo », sans utiliser le programme « sudo ». C'est donc un système parallèle qui prend arbitrairement ces utilisateurs là…
(Polkit est le mécanisme qui permet, lorsque tu lances gparted en tant qu'utilisateur membre du groupe sudo, mais sans taper « sudo », d'augmenter les privilèges de l'application et lui permettre de lancer des repartitionnements/formatages nécessitant les droits root).
Le système Debian propose, par défaut , trois type de compte , qui sont caractérisés chacun par leur capacité à accéder ou non, aux privilèges-root et à certains privilèges-utilisateur.
Cette notion de « type d'utilisateur » n'existe pas. La rajouter… rajoute de la confusion. Notamment, un débutant lisant ça ne pourra pas discuter avec un expert, parce que ce n'est pas le même langage. La longueur de ce sujet et la véhémence de certaines réactions en est la preuve.
Tu cherches à catégoriser les utilisateurs suivant le pouvoir qu'ils ont ? Ok, alors je te propose ça :
Il existe un utilisateur particulier, appelé super-utilisateur ou par son nom d'utilaseur, root, disposant de tous les droits sur le système et donc en capacité d'administrer celui-ci.
Les humains (et programmes) peuvent également disposer de comptes utilisateurs. Ceux-ci peuvent parfois accéder aux fonctions (partielles ou totales) d'administrateurs via délégation. Par exemple, si vous ne saisissez pas de mot de passe root lors de l'installation, le premier utilisateur créé appartiendra au groupe sudo auquel sont délégués les droits d'exécuter n'importe quel programme en tant que root.
Pour comprendre l’intérêt de chaque type de compte, il ne pas oublier que Debian est un système multi-utilisateurs conçu pour l’entreprise.
L'entreprise n'a rien à voir là-dedans. Un serveur bénéficie grandement du concept de multi-utilisateurs, alors-même qu'il ne possède souvent qu'un seul utilisateur humain.
L'intérêt du multi-utilisateur consiste en la compartimentation des droits de chaque programme et de chaque humain.
Dans ce cas de figure, l’ utilisateur NP et l’ admi sudo
« utilisateur NP » et « admin sudo » sont deux termes que tu inventes. Ils ne seront pas compris par des experts parce que dans l'absolu, ils n'ont pas de sens. Ils correspondent à une situation quasi accidentelle, c'est le ciel que voit la grenouille au fond du puits, ce ne sont, à mon avis, pas des repères stables.
La plupart des utilisateurs d'un système ne sont pas dans le sudoer. La distinction utilisateur humains/utilisateurs systèmes ne fait pas de sens pour le système. Et dans ce cadre, un « utilisateur NP » ça s'appelle « un utilisateur ». Un utilisateur privilégié, ça s'appelle « root », et un utilisateur pouvant devenir root via sudo, ça s'appelle un utilisateur pouvant passer root via sudo.
Le compte root (appelation GUI et CLI)=administrateur root=super-utilisateur
« appelation GUI » et « appelation CLI », ce sont des termes/notions que tu inventes. Je ne comprends pas ce qu'elles veulent dire.
c’est à dire que les permissions ne s’appliquent pas.
Ce n'est pas vrai, on peut empêcher root de modifier un fichier, via « chattr », cf https://www.linuxnix.com/how-to-prevent … -in-linux/
L’uilisateur principal :
De ce que j'ai compris, « utilisateur principal » est utilisé par polkit pour désigner un utilisateur administrateur, et dans les tuto ubuntu pour désigner un membre du groupe sudo.
Là aussi, c'est une notion qui mérite démystification.
Le groupe sudo est le seul groupe dont le rattachement à un compte permet l’acquisition des privilèges root pour ce compte.
Je préfère dire que c'est « par défaut » le seul. Je sais que tu parles du comportement par défaut, mais il ne faudrait pas que les gens comprennet que c'est le seul « dans l'absolu. »
Les deux comptes non-root (admi sudo et utilisateur NP) peuvent être personnalisés, l'inscription à un nouveau groupe permet d'obtenir un nouveau privilège. Par exemple, si l'admi sudo s'inscrit au groupe adm, il pourra consulter les journaux systèmes et les journaux utilisateurs. Egalement, si l'utilisateur NP est inscrit au groupe vidéo, par un administrateur (sudo ou root), il pourra regarder des vidéos.
C'est très bizarre dit comme ça. Tout simplement, n'importe quel utilisateur ou groupe d'utilisateurs peut recevoir de quelconques pouvoirs via différents mécanismes, tels polkit et sudo.
su = substitute user = switch user to = fermer le compte actif et basculer sur le compte de l’utilisateur xxxx.
Ce n'est pas ce qu'il se passe.
Il ne faut pas parler de compte, mais de processus.
L'utilisateur tapant su, ou sudo, le tape dans un shell (bash par exemple), lancé dans un terminal (le plus souvent virtuel, tel xterm ou gnome-terminal). Ce shell tourne avec les droits de l'utilisateur.
Lorsque l'utilisateur lance su ou sudo, ce programme s'exécute en tant que fils du shell, et avec les droits root, car ces programmes sont setuid, ils s'exécutent donc non-pas avec les droits de ceux qui les lancent, mais avec les droits de ceux qui les possèdent. Ces droits root permettent dans un premier temps de vérifier les mots de passe éventuels, les règles de délégation, et, enfin, de lancer (ou non) le programme souhaité avec les droits voulus.
Exemple : « su -l jojo » va s'exécuter en root, demander le mot de passe de jojo, vérifier le mot de passe, puis s'il est valide lancer le shell de jojo en tant que jojo (donc abaisser ses privilèges). Une fois ce shell terminé, le programme parent, c'est à dire le shell dans lequel l'utilisateur a tapé la commande, va reprendre la main. Il n'a jamais été fermé pendant tout ce temps, il n'avait simplement pas la main.
« su -c "/bin/true" » va demander le mot de passe root, puis exécuter un shell root exécutant la commande /bin/true… Et rendre immédiatement la main, à la manière de sudo.
On obtient donc le terminal root, c'est à dire une ouverture permanente des privilèges root. Il est donc fortement déconseillé de se connecter à internet ou de laisser son ordinateur sans surveillance.
Là aussi, c'est approximatif et donne une règle sans expliquer le pourquoi. La raison est simple: dans ce shell root (et non-pas terminal, le terminal tourne toujours avec les droits utilisateur, seul le shell tourne avec les droits root), tous les programmes lancés ont les pleins pouvoirs sur la machine, il est donc important qu'ils soient sûrs, et ne puissent compromettre la machine. Donc, lancer un programme graphique, voire pire, un navigateur web graphique, c'est prendre un risque important (surtout quand on est débutant)
A la différence de sudo, su ne constitue pas un groupe.
Ceci est ambiguë. Il y a homonymie entre /usr/bin/sudo et le groupe sudo. Et le sens de « constitue » n'est pas clair. Cette phrase n'est pas compréhensible par un expert.
Sudo est un utilitaire qui permet de sécuriser l'accès à root en paramétrant la durée d'ouverture des privilèges root, et ceci sans basculer dans le terminal root.
Non, c'est très abusif de dire ça.
sudo ne sécurise pas vraiment l'accès au compte root, et surtout pas dans sa configuration par défaut. Sans sudo, pour être root, un attaquant doit trouver le pass root ou une faille dans un programme tournant en tant que root. Avec sudo, pour être root, un attaquant peut soit trouver le pass root s'il existe, soit trouver une faille dans un programme tournant en tant que root, soit trouver le pass d'un utilisateur du groupe sudo, soit trouver une faille dans un programme tournant en tant que l'utilisateur du groupe sudo et attendre le bon moment pour lancer la commande sudo.
Bref, ça ne fait que rajouter ou déplacer des failles potentielles.
L'intérêt sécurisant de sudo est que 1) en général, il est associé à un système dans lequel root n'a pas de pass, celui-ci ne peut donc pas être deviné, et pour deviner le pass de l'utilisateur, il faut deviner le nom d'utilisateur. Ceci-dit, ce nom d'utilisateur n'est pas forcément secret, on ne peut donc pas compter sur cette difficulté supplémentaire. 2) sudo permet de ne déléguer que partiellement des droits. C'est cette possibilité, non-utilisée par défaut, et par les débutants, qui permet de sécuriser le système en délégant moins, et en lançant en tant qu'utilisateur sudoer mais non membre du groupe sudo, un programme qui sinon pourrait nécessiter les droits root. On peut par exemple grace à cela permettre à un utilisateur humain de lancer une commande « logrotate » en root quant il veut, sans pour autant pouvoir lancer un rm en root.
Il est posible de configurer sudo pour fonctionner comme su (sudo -i) et vice-versa (su -c), mais alors, pourquoi dit-on que sudo est plus sécurisé que su?
Est-ce que su -c est moins sécurisé que sudo avec timeout=0 ?
Il ne faut pas croire ce que l'« on dit », surtout quand « on dit » également le contraire.
Mais, oui, c'est possible. Tu as un exemple ici de comment faire joujou avec PAM, le système d'authentification utilisé par su :
https://unix.stackexchange.com/question … t-password
Je ne sais pas comment clonner exactement le comportement de sudo, ce n'est peut-être pas possible ou très difficile, mais les mécanismes en jeu sous le capot restent les mêmes.
Je pense qu’il peut être intéressant en matière de sécurité qu’il y ait plusieurs super-utilisateurs sur un système. Mais comment fait-on pour créer ‘’proprement’’ un nouveau super-utilisateur, c’est à dire avec un environement complet (similaire à celui de root) et donc avec tous les liens que cela implique ?
cf « man useradd » pour les détails des options.
Mais, comme dit plus haut, ce n'est pas une bonne idée. Le seul avantage d'avoir plusieurs super-utilisateurs, c'est que si un utilisateur veut se logguer en root avec un shell zsh et son home à lui dans /root, et un autre veut se logguer avec un shell bash avec son home dans /root-marcel, ils peuvent. Mais l'un comme l'autre pourront modifier les fichiers et les mots de passe de l'autre. Ça n'apporte aucune sécurité, seulement une porte d'entrée supplémentaire.
Pourquoi le référencement-Google de cette discussion est il si mauvais ?
Aucune idée. Peut-être parce que la discussion est récente, ou que le robot indexeur de google déprime qd il voit des messages aussi longs.
captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.
Hors ligne