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

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?

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).

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.

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.

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

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.

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.

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.

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.