Quelle est la nécessité de la commande `fakeroot` sous Linux?

93

Pourquoi avons-nous besoin de fakerootcommandement? Ne pouvons-nous pas simplement utiliser les commandes sudoou su?

La page de manuel dit:

fakeroot - lance une commande dans un environnement simulant les privilèges root pour la manipulation de fichiers

About.com dit:

Donne un faux environnement racine. Ce paquet est destiné à permettre quelque chose comme: dpkg-buildpackage -rfakerootc'est-à-dire qu'il n'est plus nécessaire de devenir root pour créer un paquet. Cela se fait par la mise LD_PRELOADà libfakeroot.so, qui fournit des emballages autour getuid, chown, chmod, mknod, stat, ..., créant ainsi un environnement de racine faux. Si vous ne comprenez rien à cela, vous n'en avez pas besoin fakeroot!

Ma question est, quel but spécial cela résout-il si simple suou sudopas? Par exemple, pour reconditionner tous les packages installés dans Ubuntu, nous donnons la commande suivante:

$ fakeroot -u dpkg-repack `dpkg --get-selections | grep install | cut -f1`

Peut-on faire la commande ci-dessus avec sudo ou su au lieu de fakeroot comme ceci:

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`

MODIFIER:

Fonctionnement:

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`

me donne cette erreur:

Le répertoire de contrôle a de mauvaises autorisations 700 (doit être> = 0755 et <= 0775)

Une raison pour laquelle?

gkt
la source
6
il est judicieux, pour des raisons de sécurité, d'éviter de faire en tant que root tout ce qui pourrait être fait en tant qu'utilisateur normal, même si vous pouvez exécuter sudoou suparce que c'est votre machine. fakeroota deux usages 1) il trompe les programmes en leur faisant croire que vous êtes bien un utilisateur root, ce que certains logiciels propriétaires mal écrits peuvent nécessiter même s’ils ne sont pas nécessaires (généralement les développeurs Windows sont passés sous Linux) et 2) il permet d’émuler les changements de mode et de propriété que vous ne voudriez pas. t autrement pouvoir le faire, principalement pour créer un tarfichier avec les permissions et la propriété appropriées, utile par exemple lors du packaging d’un logiciel.
pqnet
1
Je pense que la note dans l'extrait de About.com le résume: Si vous ne comprenez rien à cela, vous n'en avez pas besoin fakeroot! Si vous ne pouvez pas penser à une situation où il fakerootest utile, alors vous n'en avez littéralement pas besoin. Mais les personnes qui en ont réellement besoin comprennent parfaitement le cas d'utilisation.
Christopher Schultz

Réponses:

69

Imaginez que vous soyez un développeur / mainteneur de paquet, etc. travaillant sur un serveur distant. Vous souhaitez mettre à jour le contenu d'un paquet et le reconstruire, télécharger et personnaliser un noyau depuis kernel.org et le construire, etc. Tout en essayant de faire cela, vous découvrirez que certaines étapes nécessitent que vous possédiez des rootdroits ( UIDet GID0) pour différentes raisons (sécurité, autorisations négligées, etc.). Mais il n’est pas possible d’obtenir des rootdroits, car vous travaillez sur une machine distante (et de nombreux autres utilisateurs ont le même problème que vous). C'est ce que fakerootfait exactement : il prétend efficace UIDet GIDde 0 à l'environnement qui les requiert.

En pratique , vous n'obtenez de véritables rootprivilèges (en face de suet sudoque vous mentionnez).

Sakis
la source
alors, je ne peux pas utiliser fakerootpour modifier les paramètres du système? Parce que la commande que nous allons exécuter pensera qu’elle est exécutée en tant que root et fera ce que nous voulons. n'est-ce pas?
MRID
3
@mrid Notez "En pratique, vous n'obtenez jamais de vrais privilèges root". Donc, la réponse est non
sakisk
53

Pour voir clairement la différence entre fakeroot et un vrai sudo / su, il suffit de faire:

$ fakeroot
# echo "Wow I have root access" > root.tst
# ls -l root.tst
-rw-rw-r-- 1 root root   23 Oct 25 12:13 root.tst
# ls -l /root
ls: cannot open directory /root: Permission denied
# exit
$ ls -l root.tst
-rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst

Tant que vous êtes dans le shell fakeroot, cela ressemble à un utilisateur root, tant que vous n'essayez pas de faire quoi que ce soit qui nécessite réellement des privilèges root. Et c’est exactement ce dont un outil de conditionnement a besoin pour créer des packages qui auront un sens sur n’importe quelle machine.

En fait, lorsque vous utilisez fakeroot pour l’emballage, vous souhaitez que les outils que vous exécutez sous fakeroot affichent vos fichiers comme appartenant à root. Ni plus ni moins. Donc, en fait, su ou sudo ne fonctionnera pas pour obtenir la bonne propriété de fichier.

MortenSickel
la source
Faker n'est pas dangereux? Si je crée un fichier avec suid bit et rx perm, le fichier sera créé et sera la propriété de root, exécutable par n'importe qui, en tant que root! Ou peut-être que régler le bit suid ne fonctionnera pas?
Frizlab
7
Pas bien. J'ai essayé cela moi-même. La raison principale de fakeroot est d'obtenir la propriété root: root dans les packages construits sans être réellement root. les paquets installés auront des permanentes appropriées, cependant.
hanetzer
2
C'était très déroutant jusqu'à ce que je lise le commentaire de @ ntzrmtthihu777!
Shahbaz
Désolé, je ne comprends pas la description. Pourquoi ne pas patcher les outils pour qu'ils ne se plaignent pas si vous n'êtes pas root? Comme une question connexe: Après tout, les fichiers que vous créez fakeroot ne sont pas réellement la propriété de root. Cela ne signifie-t-il pas que lorsque j'installe un tel .debfichier, tous mes /usrfichiers appartiennent à l'utilisateur que l'utilisateur a appelé fakeroot?
Johannes Schaub - lundi
@ JohannesSchaub-litb, non, c'est ce qui compte. Les fichiers ne sont pas la propriété de root, mais dans un fakerootshell, ils ont l’ air d’ être. Lorsque le package .deb est créé dans ce shell, le propriétaire du fichier est lu à partir du système de fichiers (qui fakerootintercepte et renvoie root) et stocké dans le package. Lors de l'installation du package, dpkg nécessite alors un accès root, car il indique que le fichier doit appartenir à root.
Shahbaz
45

Comme les réponses sont difficiles à comprendre (pour moi-même) et qu'il a fallu un peu de réflexion pour le comprendre ( ce commentaire m'a permis de le comprendre), je vais donner une meilleure explication si tout va bien.

1. Qu'est-ce qui se passe dans fakeroot

Rien de plus que ce qui se passe avec votre propre utilisateur. Absolument rien de plus. Si vous fakeroot(qui, à l'appel, vous donne un nouveau shell, par exemple sudo), faites semblant de faire des choses pour lesquelles vous aviez besoin d'une permission, et quittez, rien ne se passera.

Si vous y réfléchissez, c'est une perte de temps totale. Pourquoi voudriez-vous faire des choses qui ne se produiront pas? C'est fou. Vous auriez simplement pu ne rien faire et il n'y aurait eu aucune différence, puisqu'il n'y a aucune trace.

Attends une minute...

2. La trace de fakeroot

Il pourrait y avoir une trace de fakeroot. Regardons les commandes de la réponse de MortenSickel qui est très jolie et mérite un vote positif:

$ fakeroot
# echo "Wow I have root access" > root.tst
# ls -l root.tst
-rw-rw-r-- 1 root root   23 Oct 25 12:13 root.tst
# ls -l /root
ls: cannot open directory /root: Permission denied
# exit
$ ls -l root.tst
-rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst

Au premier coup d'œil, il semble que le fait de l'utiliser fakerootsoit une perte de temps totale. En fin de compte, si vous n'aviez pas utilisé fakeroot, vous auriez la même chose.

La chose subtile ici est la suivante:

$ cat root.tst
Wow I have root access

Ce qui signifie que le contenu du fichier se souvient toujours d’être une racine. Vous pourriez dire que ne pas utiliser fakerootaurait produit les mêmes résultats. Vous avez raison, cet exemple est trop simple.

Prenons un autre exemple:

$ fakeroot
# touch x
# touch y
# chown myuser:myuser x
# ls -l > listing
# exit
$ ls -l
total 4
-rw-rw-r-- 1 myuser myuser 152 Jan  7 21:39 listing
-rw-rw-r-- 1 myuser myuser   0 Jan  7 21:39 x
-rw-rw-r-- 1 myuser myuser   0 Jan  7 21:39 y
$ cat listing
total 0
-rw-rw-r-- 1 root   root   0 Jan  7 21:39 listing
-rw-rw-r-- 1 myuser myuser 0 Jan  7 21:39 x
-rw-rw-r-- 1 root   root   0 Jan  7 21:39 y

Voyons ce qui se passe. Je prétendais être root, ce qui est totalement inefficace, et créé xet y. J'ai prétendu xappartenir myuseret yappartenir à root. En fait, ils appartiennent tous les deux myuser(comme nous pouvons le voir à la fin), mais je prétendais que c'était comme ça.

Ensuite, j'ai créé une liste et enregistré mon imagination dans un fichier. Plus tard, lorsque je regarde le fichier, je peux voir à qui je pense que les fichiers devraient appartenir. Encore une fois, ils n'appartiennent pas à des personnes que j'imaginais, je les imaginais simplement.

3. Alors ... pourquoi tu veux ça encore?

Vous pouvez dire que je n'avais pas vraiment besoin de faire semblant d'être root pour créer cette liste. J'aurais pu simplement créer la liste, puis la modifier pour refléter mon imagination. Tu as raison, tu n'avais pas besoin fakerootde ça. En fait, sachant que fakerootcela ne fait rien, vous ne pouvez avoir acquis aucune capacité que vous n'aviez pas auparavant.

Mais , et c’est tout ce dont il fakeroots’agit, la modification de la liste pourrait ne pas être triviale. Comme dans le cas d'un package pouvant être installé sur votre système, vous disposez d'un format tared, gziped, xzed, bzip2ed ou de tout autre format permettant de conserver vos fichiers ensemble et de vous rappeler leurs autorisations et leurs propriétaires. Pouvez-vous facilement modifier le fichier compressé et modifier la propriété d'un fichier? Je ne sais pas pour vous, mais je ne peux pas penser à un moyen.

Pourrait-il y avoir un outil construit qui, une fois que tout est compressé, modifie le fichier compressé et édite par programme les droits de propriété et les autorisations? Oui il pourrait. Vous pouvez donc simuler les propriétés avant la compression ou les modifier après. Les gens de Debian ont décidé que le premier était plus facile.

4. Pourquoi ne pas simplement utiliser sudo?

Tout d'abord, vous n'avez pas besoin des privilèges root pour créer des logiciels ni des privilèges root pour les compresser. Donc, si vous n'en avez pas besoin, vous devez vraiment être un utilisateur Windows pour même penser à obtenir cette permission. Mais à part le sarcasme, vous n’avez peut-être même pas le mot de passe root.

De plus, supposons que vous ayez les permissions root. Et disons que vous voulez prétendre qu'un fichier doit avoir un accès en lecture uniquement à la racine. Donc, vous sudochangez le propriétaire du fichier et les autorisations en root, vous sortez du shell root et essayez de tout empaqueter. Vous échouez car vous ne pouvez plus lire le fichier car vous n’avez pas accès à la racine. Donc, vous devez sudocompresser et construire le paquet en tant que root. Effectivement, vous devez tout faire en tant que root.

C'est mauvais TM .

En tant qu'emballeur, vous n'avez pas besoin d'autorisations root et vous ne devriez pas l'obtenir. Lorsque vous installez un paquet, vous devrez peut-être installer un fichier ( A) en tant que root. C'est là que vous avez besoin d'autorisations root. Tout fakerootest fait pour rendre cela possible. Il laisse la liste des emballeurs Acomme appartenant à root pour l’archiveur. Ainsi, lorsque le package est décompressé par l’utilisateur, l’archiveur demande l’autorisation root et crée Acomme appartenant à root.

Shahbaz
la source
5
Excellente rédaction, cela est clair.
Christian Long
1
So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier.Cela m'a aidé alors que je continuais à penser "pourquoi ne pas le modifier après?".
aaaaaa
1
Merci, cela efface la confusion que j'avais après avoir lu la réponse de @ Morten
Johannes Schaub - lundi
33

Autant que je sache, fakeroot exécute une commande dans un environnement dans lequel il semble disposer de privilèges root pour la manipulation de fichiers. Ceci est utile pour permettre aux utilisateurs de créer des archives (tar, ar, .deb, etc.) contenant des fichiers avec des autorisations / droits de root. Sans fakeroot, il serait nécessaire de disposer des privilèges root pour créer les fichiers constitutifs des archives avec les autorisations et les droits de propriété appropriés, puis de les assembler ou de construire les archives directement, sans utiliser l'archiveur.

fakeroot fonctionne en remplaçant les fonctions de la bibliothèque de manipulation de fichiers (chmod (), stat (), etc.) par des fonctions simulant l'effet que les fonctions de bibliothèque réelles auraient eu si l'utilisateur avait réellement été root.

Synopsis:

 fakeroot [-l|--lib library] [--faked faked-binary] [--] [command]  

Vérifiez plus ici: fakeroot


la source
@MaskTheSmokin: Donc, fakeroot vous donne le pouvoir de super-utilisateur uniquement pour les opérations de manipulation de fichier, d'accord.
dimanche
@ gkt.pro: Je suppose que oui.
10
Il ne donne pas vraiment le pouvoir du super utilisateur, il le simule - le programme qui y est exécuté pense avoir les privilèges root, alors qu'il utilise toujours les privilèges normaux de l'utilisateur.
Paŭlo Ebermann
2
Où est la différence entre the program running in it thinks it has root privilegeset le programme ayant les privilèges root? Si je peux faire un rm -rf /et le programme, en l'exécutant, je pense avoir les privilèges root ...
utilisateur inconnu
10
@userunknown Vous pouvez peut-être ignorer la rmvérification de vos autorisations suffisantes, mais le noyau lui-même ne vous le permet pas. l' unlinkappel système échouerait. Ce n'est pas à l'application seule de gérer les autorisations, ou vous seriez capable d'écrire votre propre application qui ne vérifie pas les autorisations et en fait ce que vous voulez
Michael Mrozek
11

Je l'ai utilisé pour les scripts de construction de paquets. Je n'étais pas sûr que la personne qui exécute le script dispose d'un accès de niveau racine, mais le script devait tout de même générer, par exemple, un fichier tar contenant des fichiers appartenant à la racine. Le moyen le plus simple de le faire était d’exécuter le script de création de paquet sous fakeroot, ce qui a amené l’archiveur à croire que les fichiers appartenaient à root et à les regrouper comme tels dans l’archive. Ainsi, lorsque le package a été décompressé sur la machine de destination (sur une autre machine), les fichiers n'appartenaient pas à des utilisateurs étranges ou inexistants.

En y réfléchissant, le seul endroit où j'ai vu ceci était pour construire une sorte d'archive: les rootfs des systèmes embarqués, les archives tar.gz, les paquetages rpm, les paquetages .deb, etc.


la source
1
fakerootest un outil de contournement pour les logiciels de packaging buggés: il n’ya aucune raison que vous soyez root pour créer de tels packages, mais comme ils ne vous permettent pas de spécifier des autorisations de fichiers autrement que de les définir directement au préalable dans le système de fichiers, vous n’avez choix
pqnet
3

Un usage courant est de savoir quels fichiers un binaire défaillant voulait vraiment accéder. C'est-à-dire rechercher et corriger des bogues causés par des chemins codés en dur et une gestion incorrecte des exceptions ou y remédier.

Eero Ketonen
la source
1

Vous pouvez utiliser fakeroot sans avoir les privilèges root. Si vous aviez suet / ou sudoseriez en mesure de détruire votre système avec un simple rm -rf /, mais avec fakeroot au plus, vous supprimeriez votre répertoire personnel.

gabrielhidasy
la source
2
Cela n'explique pas la nécessité de fakeroot. Vous pouvez supprimer votre répertoire personnel comme vous-même.
JMCF125
1

La réponse simple:

su et sudo exécutent les commandes en tant que root. fakeroot ne le fait pas, en dehors de son arrangement partiel de bac à sable.

Jdmayfield
la source