Puis-je créer un * super * super-utilisateur afin d'avoir un utilisateur pouvant refuser l'autorisation de root?


34

Je pensais qu'il pourrait être avantageux d'avoir un utilisateur avec des autorisations supérieures à l'utilisateur root.

Vous voyez, je voudrais garder toutes les activités et presque tous les privilèges d’utilisateur root existants exactement tels qu’ils sont maintenant.

Cependant, je souhaiterais que la possibilité de refuser des privilèges s’enracine de manière extrêmement isolée au cas par cas.

L'un des avantages de cette solution me permettrait d'empêcher l'installation de certains fichiers indésirables lors des mises à jour. Ceci n'est qu'un exemple d'un avantage possible.

Comme les mises à jour d'apt-get sont exécutées à la racine ou avec les privilèges sudo, apt-get peut remplacer certains fichiers indésirables lors des mises à jour.

Si je pouvais refuser ces privilèges à ces fichiers particuliers, je pourrais les définir comme lien simulé vers /dev/nullou éventuellement avoir un fichier fictif vierge qui pourrait avoir des autorisations qui empêcheraient le fichier d'être remplacé lors de la mise à jour.

De plus, je ne peux pas m'empêcher d'être rappelé d'une phrase qui a été dite dans une interview avec l'un des créateurs d'Ubuntu, quand le gars a dit quelque chose sur la façon dont les utilisateurs ont davantage confiance en "nous" (faisant référence aux développeurs Ubuntu) "parce que nous avons root "qui était une référence à la façon dont les mises à jour du système sont effectuées avec la permission du root.

Changer simplement la procédure d'installation pour dire que contourner ce problème n'est absolument pas ce qui m'intéresse ici. Maintenant que mon esprit a le goût d’avoir le pouvoir de refuser l’accès root, je voudrais trouver un moyen d’y arriver simplement pour le faire.

Je viens de penser à cela et je n’ai pas passé autant de temps sur l’idée jusqu’à présent et je suis assez confiant que cela pourrait être compris. Cependant, je suis curieux de savoir si cela a déjà été fait ou s'il ne s'agit peut-être pas d'une idée ou d'un concept nouveau.

Fondamentalement, il semble qu'il devrait y avoir un moyen d'avoir un super-utilisateur qui aurait une permission au-delà de celle du système à un degré près.


Remarque: Bien que je pense que la réponse acceptée correspond le mieux aux critères, j'aime beaucoup la réponse de @CR. également.

J'aimerais créer un utilisateur réel plus haut sur l'arbre (moi), mais je suppose que je devrai simplement m'asseoir un jour lorsque j'aurai le temps de le comprendre.

De plus, je n'essaie pas de choisir Ubuntu ici; Je ne l'utiliserais pas comme distribution principale si je me sentais négatif à ce sujet.


4
De quel type de fichiers parlez-vous et pourquoi? " empêcher l'installation de certains fichiers indésirables _" suggère que les fichiers n'existent pas (normalement) et que vous souhaitez les arrêter; mais "ce qui empêcherait le fichier d'être remplacé lors de la mise à jour " suggère que les fichiers existent déjà (avec un contenu supposé souhaitable) et que vous ne voulez pas de nouvelles versions.
TripeHound

6
Sachez que toute méthode qui empêche aptd'écrire (sur) des fichiers peut conduire à une erreur et à l'abandon du processus de mise à jour. aptrefusera alors de faire des mises à jour ou des installations jusqu'à ce que le "problème" soit résolu.
Dubu

6
"Simplement modifier la procédure d'installation pour dire que le contournement de ce problème n'est absolument pas ce qui m'intéresse ici." Peut-être que oui, mais c'est généralement la bonne façon de résoudre le problème comme indiqué. Il est possible de limiter root (officiellement, root-in-userland n’a pas le même niveau d’accès que le mode noyau) et il existe des systèmes pour l’accomplir, mais cela va à l’encontre de la philosophie Unix et des principes de sécurité de base. En général, une fois qu'une personne a une racine "partielle", il est exceptionnellement difficile de mettre en liste noire tout ce qu'elle peut utiliser pour obtenir une racine "complète". Préfère ne donner que la racine au code de confiance.
Kevin

8
@mchid: root est un contrôle total. C'est le but de tout ça. Afin de ne pas avoir le contrôle total, vous devez refuser tellement de choses que cela ne ressemble plus à la racine (par exemple, aucune installation de modules de noyau, aucun montage de périphériques arbitraires, etc.). Si vous ne voulez pas exécuter les tâches en tant que root, ne les exécutez pas en tant que root. Au lieu de cela, distribuez des fonctionnalités (à l'exception de toutes celles équivalentes à la racine , ne vous en occupez pas) ou exécutez un démon tel que polkitd qui effectue des opérations root pour le compte de processus non-root.
Kevin

4
@ mchid: Voilà le problème: les programmes disposent d'un grand nombre de moyens pour contourner vos restrictions. À moins que vous ne mettiez toutes ces méthodes dans la liste noire, tout programme que vous exécutez en tant que "racine restreinte" peut toujours devenir une racine complète à tout moment. Donc, tout votre stratagème n'est rien de plus qu'une charade du théâtre de la sécurité.
Kevin

Réponses:


83

L'utilisateur que vous souhaitez s'appelle LSM: module de sécurité Linux. Les plus connus sont SELinux et AppArmor.

Ainsi, vous pouvez empêcher certains fichiers binaires (et leurs processus enfants) d'effectuer certaines tâches (même si leur UID est root). Mais vous pouvez autoriser ces opérations gettyet ses processus enfants afin de pouvoir le faire manuellement.


2
Mais si leur UID est root, ne peuvent-ils pas modifier les autorisations selinux qui les empêchent d’accéder en premier lieu?
strange_cat

11
@curious_cat: Oui, bien sûr, vous devez refuser à un processus "racine limitée" la possibilité de modifier / élever sa propre autorisation! Les personnes qui ont écrit SELinux pensaient déjà à cela ...
Peter Cordes

8
@curious_cat Vous pouvez configurer les LSM de sorte qu'il soit complètement impossible de modifier leur configuration au moment de l'exécution. Vous devez redémarrer et donner un paramètre de noyau pour pouvoir le faire ensuite.
Hauke ​​Laging

5
@ Joshua Si votre copie d'apt-get utilise Rowhammer, vous avez de plus gros problèmes à vous inquiéter.
Draconis

3
@corsiKa Tout d'abord, vous souhaitez limiter les personnes pouvant démarrer la machine aux personnes qui se trouvent réellement sur la machine, car les systèmes sont vulnérables lors du démarrage. Déclencher un redémarrage sur le réseau est acceptable, mais permettre le contrôle au démarrage ne l’est pas. Deuxièmement, une règle de sécurité informatique est que vous ne pouvez rien faire une fois qu'un attaquant a un accès physique, car ils peuvent tout aussi bien dunk tout dans LN2 / rewire le matériel / etc. Donc, oui, quelqu'un qui peut modifier le démarrage d'une machine est généralement supposé avoir "gagné" la machine.
HTNW

51

Vous comprenez mal le concept d' rootutilisateur.

En clair, rootc'est au "sommet de l'arbre".

Et si vous décidiez un jour d'avoir un "super super utilisateur", puis le mois prochain un "super super super utilisateur" (!). Jusqu'où voulez-vous aller dans l'arbre? Comment mélangeriez-vous toutes les autorisations et la hiérarchie pour que cela fonctionne? Qui est toujours au top? Quelqu'un doit être au sommet, et c'est root. Fin de l'histoire.

Les solutions proposées ici - y compris AppArmor et SELinux - ne changent pas vraiment cela. Ils permettent simplement un contrôle plus fin du grain sur les rootautorisations et les processus.

Il me semble que votre processus de mise à jour ne convient pas au résultat souhaité. Mais ce n'est pas du tout la faute de l' rootutilisateur. Plutôt que de trop compliquer les choses, considérez-le rootcomme le plus haut utilisateur, et ensuite, vous devez travailler à la baisse.

Je sais que certaines personnes noteront cela, mais il n'y a pas de niveau supérieur dans la hiérarchie des utilisateurs, et toutes les autres solutions donnent simplement un contrôle légèrement différent du fonctionnement des rootautorisations. Mais ils ne créent pas un nouvel utilisateur, avec des autorisations plus élevées.

Vous ne pouvez pas avoir un utilisateur avec "plus d'autorisations" que rootparce que rootreprésente le plus haut niveau d'autorisations possible. Utiliser une phrase telle que "plus de contrôle que root" est une contradiction - rootcontrôle total et toutes les autorisations possibles, donc rien ne peut être fait au-dessus.


Je serais au sommet pas racine, fin de l'histoire. Parce qu'il n'y a pas de niveau supérieur dans la hiérarchie des utilisateurs, c'est la raison exacte pour laquelle je souhaite créer un utilisateur supérieur.
mchid

Bien que, c’est un peu ce que je veux: contrôler les autorisations et les processus root afin de pouvoir refuser l’autorisation à root. Si je peux en quelque sorte refuser l'autorisation de root sans créer un nouvel utilisateur avec SELinux ou AppArmor, je suppose que je n'ai pas besoin d'un nouvel utilisateur. Je veux un contrôle total, plus de contrôle que root.
mchid

16
Vous ne pouvez pas avoir un utilisateur qui a "plus d'autorisations" que root. C'est tout le problème. L'utilisateur que vous souhaitez créer est essentiellement l'utilisateur root. Vous devez aborder cette question dans l'autre sens, par exemple en créant un utilisateur doté de rootprivilèges, puis en interdire à certains utilisateurs pour lesquels vous souhaitez un contrôle plus fin. Ce que vous demandez ("plus de contrôle que la racine") n'est pas possible, ni même une chose!
Andy

@ mchid Donc, ce que vous voulez réellement faire est de renommer l'utilisateur root actuel en mchid, de créer un nouvel utilisateur appelé root et de faire en sorte qu'apt-get et al utilisent votre nouvel utilisateur non root?
Odalrick

Sur certains systèmes, rootn’est pas autorisé à accéder directement au matériel. Si vous désactivez le chargement des modules du noyau, vous pouvez garder root bloqué sur le matériel ( /dev/memet ainsi de suite). Pas vraiment pertinent pour les autorisations de système de fichiers, car vous n'utiliseriez pas d'apt-get ayant parlé directement à votre contrôleur SATA ou NVMe ... Mais techniquement, il existe un état "plus d'autorisations que root" et s'appelle le mode noyau. : P
Peter Cordes

26

Si vous souhaitez simplement empêcher la modification / suppression de fichiers ou de répertoires, définissez simplement le drapeau immuable sur ceux-ci.

chattr +i <file>

Même root ne pourra rien leur faire à moins que le drapeau ne soit supprimé. Il est également possible d'utiliser le système conteneur / espace de noms pour empêcher l'accès root, mais cela semble excessif pour ce dont vous avez besoin.


11
Mais root peut supprimer le drapeau.
sebasth

10
apt, comme presque tout, n'utilisera pas chattr pour supprimer ce drapeau.
CR.

13
@sebasth: Correct, mais les scripts d'installation d'Apt, dpkg et par paquet ne modifieront pas (normalement) les attributs de fichier. Au lieu de cela, ils échoueront et se plaindront lorsqu'ils essaieront de modifier des fichiers avec l'indicateur immuable.
David Foerster

4
@TripeHound Donc, l'OP veut apt-getréussir à remplacer le fichier, tout en maintenant ce fichier intact? C'est un peu contradictoire j'ose dire.
Dmitry Grigoryev

3
@DmitryGrigoryev Il sonne comme ils veulent apt-getà penser qu'il a réussi , mais en laissant un ou plusieurs fichiers inchangés. Ils ne disent pas quels fichiers ni pourquoi, mais comme vous le dites, ils sont quelque peu contradictoires et sujets à un "comportement étrange" à l'avenir.
TripeHound

9
  • Au lieu d'avoir un super-super utilisateur, vous pouvez limiter root. voir Quelles sont les différentes façons de définir les autorisations de fichiers, etc. sur gnu / linux

  • Il y a aussi AppArmor et SELinux.

  • Et / ou configurez sudo-le afin de ne pas perdre tous les privilèges root. Vous pouvez le configurer de sorte qu'un utilisateur ne puisse exécuter que des commandes pré-convenues, avec des arguments pré-convenus.

  • Vous pouvez également utiliser la virtualisation pour limiter root:

    • cgroups, namespaces, chroot, etc. (c'est ce que docker fait)
    • Xen
    • Virtualbox
  • Voir aussi etckeeper: cette révision d'outil contrôle le /etcrépertoire et se synchronise avec apt. Par défaut, il n'est pas sécurisé. Une installation malveillante peut le saboter, mais vous pouvez également le forcer à transmettre les modifications à un référentiel de sauvegarde pare-feu.

  • Utilisation du contrôle de révision en général, avec un référentiel de sauvegarde pare-feu. Cette aide en cas de corruption accidentelle et intentionnelle et de défaillance matérielle.


Les référentiels de sauvegarde avec pare-feu peuvent se trouver sur une autre machine, sur Internet ou sur une autre machine virtuelle (ou hôte de machine virtuelle).


8

Pour des logiciels tels que APT , qui, en fonctionnement normal, nécessitent l’accès à la quasi-totalité du système, les restrictions sont problématiques. Même si vous l'empêchez d'accéder à certaines parties du système, le distributeur malveillant dispose probablement de suffisamment de possibilités pour contourner le problème. Par exemple, en remplaçant une bibliothèque ou tout simplement un fichier binaire ou en ajoutant un changement de configuration malveillant, que la racine non restreinte utilisera éventuellement.

En fonction du nombre de restrictions imposées, certains scripts d'installation risquent de ne pas fonctionner correctement.

Pour restreindre les applications et les utilisateurs, vous pouvez écrire une stratégie AppArmor ou SELinux. Cette politique dépend davantage de votre distribution: les bases basées sur Debian prennent mieux en charge AppArmor, tandis que les distributions basées sur Fedora / RHEL activent SELinux par défaut.

AppArmor et SELinux fonctionnent tous deux sur des stratégies de liste blanche , qui contiennent des règles permettant (ou interdisant) des actions spécifiques. Les stratégies sont appliquées à un processus lors de l' exécution . De même, les utilisateurs peuvent être restreints lorsqu'une stratégie est appliquée à leurs processus lors de la connexion. Une politique bien pensée ne peut être contournée (si les bogues du noyau ne sont pas pris en compte). Les processus confinés exécutés en tant que root (uid 0) sont limités par la stratégie configurée et ne peuvent pas être modifiés sauf autorisation explicite dans la stratégie.

Le langage de stratégie AppArmor définit une règle de refus , qui peut être utilisée pour créer une stratégie de liste noire . AppArmor est un bon point de départ pour consulter les pages de manuel d' AppArmor , son wiki et la configuration existante de votre distribution /etc/apparmor.d/.

Le matériel d’administration et de développement SELinux est fourni dans le wiki SELinux . La politique de référence de SELinux est hébergée sur github.


7

Je n'arrive pas à croire que personne n'ait mentionné le fait d'épingler ...

Il y a quelques années, Microsoft a publié un correctif qui empêchait les ordinateurs Windows 10 de communiquer avec nos anciens contrôleurs de domaine Samba NT4. Lorsque le problème a été détecté, nous avons épinglé le package Samba pour rester à la version actuelle, et aptnous fonctionnions toujours correctement.

Une procédure pas à pas complète de Debian explique bien le processus:

Dans /etc/apt/preferences(ou dans un nouveau fichier sous /etc/apt/preferences.d/), ajoutez du texte pour spécifier quel package et quelle version:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Consultez la documentation pour connaître la syntaxe exacte, mais c’est la façon rapide et incorrecte de déterminer la version d’un paquet. Root peut le contourner, comme le peut toujours faire root, mais cela résout le problème des gestionnaires de paquets qui essaient de mettre à jour automatiquement les paquets sur vous.

NOTE: Cette réponse suppose que vous avez un problème XY.


J'ai moi-même répondu à un certain nombre de problèmes XY sur askubuntu. Cependant, apt n’est qu’un exemple et c’est ce qui m’a amené à l’idée. Je suis plus intéressé par l'aspect "corrompt le pouvoir - et-absolu-le corrompt absolument" du tout. Un pouvoir complet et absolu sur mon propre système est ce qui m’a amené à Linux en premier lieu. Réaliser que mon pouvoir n'est pas toujours absolu sur la racine est un peu déroutant; L'idée du pouvoir absolu est séduisante.
mchid

De plus, je suppose que c'est un peu un problème XY mais Y voici: "comment refuser l'autorisation de root si root est le super-utilisateur?"
mchid

1
@mchid ne consiste pas à refuser les autorisations d'accès à la racine, mais à refuser quelque chose à un programme exécuté en tant que root.
John Keates

6

C'est en fait assez simple.

Root est votre "super super utilisateur"

Créez un compte appelé "admin" et donnez-lui toutes les autorisations de root, à l'exception de celles que vous ne souhaitez pas.

Créez ensuite un utilisateur appelé bob et laissez-le "devenir administrateur". En utilisant su ou même sudo.

Maintenant, vous avez un utilisateur normal (bob), un super utilisateur qui peut faire des choses admin (admin) et un super super utilisateur (root).

Si vous voulez changer le nom "root" en quelque chose d'autre, vous pouvez même le faire. Techniquement, seul l’identifiant (0) compte.


Si j’avais un utilisateur normal (bob), un super utilisateur capable de faire des tâches d’administrateur (admin) et un super super utilisateur (root), root ne ferait pas tout le travail de l’administrateur avec les processus en arrière-plan, les tâches cron, et d'autres trucs comme identifiant utilisateur (0)?
mchid

pas si vous ne le voulez pas. La plupart des services vous permettent de choisir quel utilisateur fait le travail. Vous pouvez le configurer pour que l'utilisateur admin soit celui qui exécute les processus. Il y a quelques exceptions, mais pas beaucoup.
coteyr

Est-ce que je n'aurais pas à passer par tous les processus individuellement?
mchid

3
C'est ce qui se passe lorsque vous essayez de casser les conventions standard. Je pense que vous devez mieux comprendre le comment et le pourquoi des systèmes de permissions dans un environnement * nix.
Shauna

2
Je suis d'accord avec Shauna, il semble que vous manquiez d'une compréhension fondamentale du système de permission * nix. C'est très puissant, mais ce n'est pas comme les fenêtres.
coteyr

3

Si vous souhaitez simplement empêcher l'installation de fichiers spécifiques, limiter le nombre d'autorisations root n'est pas la solution. Il convient également de noter que les réponses classiques (fichiers immuables ou LSM) ne fonctionneront pas pour votre cas d'utilisation particulier, car APT (et la plupart des autres gestionnaires de paquets) renfloueront s'ils ne peuvent pas installer de fichiers.

La vraie question que vous voulez poser est la suivante:

Existe-t-il un moyen d'empêcher APT d'installer des fichiers spécifiques?

C'est quelque chose de complètement différent de ce que vous demandez à plusieurs niveaux.

Maintenant, en ce qui concerne cette question, je ne suis pas tout à fait sûr à 100%, mais je sais qu'un certain nombre d'autres gestionnaires de paquets ont des options pour empêcher l'installation de fichiers spécifiques (par exemple, le système Portage de Gentoo a l'option INSTALL_MASK=, qui accepte style correspondant à des modèles de choses à ne pas installer). Je serais plus que disposé à parier qu'une telle option existe pour APT (ou éventuellement dpkg elle-même).


Vraiment, "Y a-t-il un moyen d'empêcher APT d'installer des fichiers spécifiques?" n'est pas ma question Ce n’est qu’un exemple et c’est ce qui m’a amené à penser à cette question. Le nouveau firefox est livré avec des addons et installe ces fichiers même après que l'utilisateur les supprime avec les nouvelles mises à jour. Ce n'est pas vraiment le problème; C'est ce qui m'a fait comprendre que je voulais encore plus de contrôle sur mon système. Cependant, j’apprécie votre logique ici car j’ai répondu à quelques questions de cette façon moi-même, alors merci pour votre contribution.
mchid

dpkg- divert
mchid

1

Placez une copie de sauvegarde dans un endroit sûr. Après toute installation / mise à jour, remplacez immédiatement les fichiers spécifiques de cette sauvegarde. Ainsi, aucune erreur ne vous empêche de tout installer, mais vous récupérez toujours le ou les fichiers que vous souhaitez conserver.


1

Travailler à partir d'un lecteur monté

Notez que ceci est principalement une réponse conceptuelle, mais je pense que cela devrait fonctionner et être dans l’esprit de ce que vous voulez réaliser.

Laissez le système X votre système de travail et le système Y un autre système que vous contrôlez.

  1. Monter un répertoire de Y en tant que lecteur dans X
  2. Configurez les droits de sorte que l'utilisateur racine de X dispose de droits sur tout le contenu de ce lecteur monté, à quelques exceptions près.

Maintenant, vous avez votre «racine active» qui peut presque tout faire et votre «super racine», le compte racine actuel du système Y, qui peut tout faire.


J'aime l'idée, bien que j'aimerais pouvoir le faire sur un système en fonctionnement.
mchid

1

Vous pouvez exécuter un hyperviseur de type 1 tel que l'hyperviseur Xen et héberger votre système d'exploitation normal en tant qu'invité virtualisé. L'hyperviseur contrôle le système d'exploitation invité virtuel à un niveau "plus profond" que la racine car il contrôle le matériel (virtuel) sur lequel le système d'exploitation invité s'exécute.

Vous pouvez programmer l'hyperviseur pour qu'il manipule le système d'exploitation invité de différentes manières, notamment en modifiant les autorisations, en créant et en appliquant des sauvegardes, en raccordant certaines modifications ou instructions dans le système d'exploitation invité pour injecter des fonctionnalités supplémentaires, une validation, etc. Ce serait un moyen valide et potentiellement utile. pour implémenter un système de type Unix avec un "utilisateur" (en réalité une fonction de l'hyperviseur) pour "faire des choses que même root ne peut pas faire"

Mon sentiment que cette approche est probablement exagérée si


Comment un hyperviseur empêche-t-il un utilisateur disposant d'une autorisation root de faire ce qu'il souhaite faire dans une machine virtuelle invitée?
fpmurphy

Cette réponse commence bien, puis s’égare grammaticalement (on lit alors dans le mauvais sens, ou du moins dans des ambigues). J'ai fait un correctif.
ctrl-alt-delor

1
@ fpmurphy1 un hyperviseur peut connecter des appels système, appliquer des stratégies, etc. pour appliquer des restrictions arbitraires à l'utilisateur root ou à toute autre partie du système d'exploitation invité. Peut-être que ma réponse n'est pas bonne parce que c'est beaucoup trop de travail à moins que vous n'ayez un cas d'utilisation réel en entreprise ou autre chose ...
Nathan Smith

@ ctrl-alt-delor Merci pour votre solution, mais je ne pense pas que la grammaire soit le problème. J'ai clarifié ce que je voulais dire cependant, et j'apprécie le fait que mes pensées n'aient pas été claires au début
Nathan Smith

1
@ fpmurphy1 dans l'invité, vous avez la racine complète. Cependant, ce n'est pas la même racine que root sur l'hôte. Par conséquent, il s'agit d'une racine inférieure à la racine de l'hôte. Docker permettra aux choses d'être plus intégrées, mais mettra toujours des restrictions sur root.
ctrl-alt-delor

1

Jetez un coup d'œil aux espaces de noms cgroups et Linux en tant que méthode alternative pour atteindre ce type d'objectif, ainsi qu'à des outils basés sur ces groupes, tels que Docker et lxd .

Ces outils vous permettent, entre autres, de limiter les parties du système de fichiers qu'un processus exécutant en tant que "root" peut voir, de limiter les processus visibles par celui-ci et de ne fournir que certaines fonctionnalités à l'utilisateur "root".


0

DÉSINSTALLER sudo

Que diriez-vous de désinstaller sudoet de lien symbolique /bin/suvers /bin/false? Ajoutez à cela le fait de vous assurer que rootvous ne pouvez pas vous connecter via sshet que vous avez verrouillé le système.

Cela rend rootle Super * Super User, et tout le monde est subordonné à cela.

Pour les fichiers remplacés lors des mises à jour, ne faites simplement aucune mise à jour. De façon plus réaliste, modifier les permissions des fichiers 440ou 444ils ne peuvent pas être écrits. Ou mettez-les dans un référentiel git afin qu'ils soient effacés s'ils sont écrasés.


Vous voyez, je veux toujours faire des mises à jour et je veux toujours que root fasse à peu près tout ce que fait normalement la racine. Cependant, je veux être capable de dire: "hey ne fais pas ça" ou "non, tu ne peux pas faire ça" comme une autorité parentale serait capable de faire à une progéniture. En l'état actuel des choses, Root est comme l'autorité parentale de mon système et tous les petits enfants disent "mère, puis-je?" quand ils utilisent sudo. C'est bon. Cependant, presque chaque personne sur cette planète est une progéniture de quelqu'un. Il semble que certaines réponses ici ressemblent à celles d'un enfant en bas âge avant la prise de conscience de soi lorsqu'il ne se rend pas compte
mchid le

. . . cette grand-mère et grand-père sont les mères et les pères de maman et papa. Je voudrais demander à grand-père de venir vivre dans mon système car, pour le moment, root est le père de la maison et grand-père peut dire à papa quoi faire, car grand-père est le père de papa :)
mchid le

Il semble que vous ayez ajouté trop de personnes dotées de pouvoirs sudo. Ajustez le sudoersfichier de sorte que seuls les utilisateurs sélectionnés puissent accéder aux commandes présélectionnées.
user176717

Je n'ai que deux utilisateurs dans le fichier sudoers, y compris root. J'essayais d'utiliser un parallèle pour expliquer comment certaines personnes semblent ne pas comprendre ma question et ce que j'aimerais réaliser.
Mchid

Il semble que les gens sentent qu'il ne peut y avoir d'utilisateur plus haut que root, de la même manière qu'un très jeune enfant pense que leurs parents ne peuvent avoir de parents. En outre, je n'ai pas eu de vote négatif.
mchid
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.