Quel est le besoin de la commande `fakeroot` sous linux
Pourquoi avons-nous besoin de la commande fakeroot? Ne pouvons-nous pas simplement utiliser les commandes Sudo ou su?
La page de manuel indique:
fakeroot - exécutez une commande dans un environnement falsifiant les privilèges root pour manipulation de fichiers
About.com dit:
Donne un faux environnement racine. Ce package est destiné à permettre quelque chose comme:
dpkg-buildpackage -rfakerootc'est-à-dire pour supprimer le besoin de devenir root pour une compilation de paquet. Pour cela, définissezLD_PRELOADàlibfakeroot.so, qui fournit des wrappers autour degetuid,chown,chmod,mknod,stat, ..., créant ainsi un faux environnement racine. Si vous ne comprenez rien à cela, vous n'avez pas besoin defakeroot!
Ma question est, quel but spécial résout-il qu'un simple su ou Sudo ne fait pas? 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`
Pouvons-nous 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 pourquoi?
Imaginez que vous êtes un développeur/mainteneur de package, etc. travaillant sur un serveur distant. Vous voulez mettre à jour le contenu d'un paquet et le reconstruire, télécharger et personnaliser un noyau à partir de kernel.org et le construire, etc. En essayant de faire ces choses, vous découvrirez que certaines étapes nécessitent que vous ayez root droits (UID et GID 0) pour différentes raisons (sécurité, autorisations ignorées, etc.). Mais il n'est pas possible d'obtenir les droits root, car vous travaillez sur une machine distante (et de nombreux autres utilisateurs ont le même problème que vous). C'est exactement ce que fait fakeroot: il prétend un UID et GID efficace de 0 à l'environnement qui les requiert.
En pratique, vous n'obtenez jamais de réels privilèges root (contrairement à su et Sudo que 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 fakeroot Shell, cela ressemble à si vous êtes root - tant que vous n'essayez pas de faire quoi que ce soit qui ait vraiment besoin des privilèges root. Et c'est exactement ce dont un outil d'emballage a besoin pour créer des emballages qui auront du sens sur n'importe quelle machine.
En fait, lorsque vous utilisez fakeroot pour l'empaquetage, ce que vous voulez réaliser est de rendre les outils que vous exécutez sous fakeroot pour voir vos fichiers comme appartenant à root. Ni plus ni moins. Donc en fait, su ou Sudo ne fonctionneront pas pour obtenir la bonne propriété de fichier.
Étant donné que les réponses sont difficiles à comprendre (pour moi-même) et qu'il a fallu réfléchir pour le comprendre ( ce commentaire m'a fait le comprendre), je vais donner une explication, espérons-le, meilleure.
1. Que se passe-t-il dans fakeroot
Rien de plus que ce qui se passe avec votre propre utilisateur. Absolument rien de plus. Si vous fakeroot (qui, une fois appelé, vous donne un nouveau shell, comme le ferait Sudo), faites semblant de faire des choses pour lesquelles vous avez besoin d'une autorisation et quittez, absolument rien ne se produira.
Si vous y réfléchissez, c'est une perte de temps totale. Pourquoi feriez-vous des choses qui ne se produiront pas réellement? C'est fou. Vous auriez pu tout simplement ne rien faire et il n'y aurait pas eu de différence, car il n'y en a aucune trace.
Attends une minute...
2. La trace de fakeroot
Il y a pourrait une trace de fakeroot. Regardons les commandes dans la réponse de MortenSickel qui est plutôt sympa 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
À première vue, il semble que l'utilisation de fakeroot était une perte de temps totale. Au final, si vous n'aviez pas utilisé fakeroot, vous auriez eu 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 fakeroot aurait 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. J'ai fait semblant d'être root, ce qui est totalement inefficace, et j'ai créé x et y. J'ai fait semblant que x appartenait à myuser et que y appartenait à root. Ils appartiennent en fait tous les deux à myuser (comme nous pouvons le voir à la fin), mais je viens de prétendre que ce soit comme ça.
J'ai ensuite créé une liste et enregistré mon imagination dans un fichier. Plus tard, quand je repense au fichier, je peux voir à qui j'imaginais que les fichiers devraient appartenir. Encore une fois, ils n'appartiennent pas à des gens que j'imaginais, je les ai simplement imaginés.
3. Alors ... Pourquoi voulez-vous à nouveau cela?
Vous pouvez dire que je n'avais pas vraiment besoin de simuler le root pour créer cette liste. J'aurais pu simplement créer la liste, puis l'éditer pour refléter mon imagination. Vous avez raison, vous n'avez pas eu besoin de fakeroot pour cela. En fait, sachant que fakeroot ne fait rien, vous ne pouvez pas avoir gagné une capacité que vous n'aviez pas auparavant.
Mais , et c'est à cela que sert fakeroot, la modification de la liste pourrait être non triviale. Comme c'est le cas avec un package qui peut être installé sur votre système, vous avez un tar ed, gzip ed, xz ed, bzip2ed ou tout autre format qui garde vos fichiers ensemble et se souvient de leurs autorisations et de 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é, il modifie le fichier compressé et modifie par programme les propriétés et les autorisations? Oui, c'est possible. Vous pouvez donc soit simuler les propriétés avant de les compresser, soit 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 et vous n'avez pas besoin 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 autorisation. Mais mis à part le sarcasme, vous pouvez même ne pas avoir de mot de passe root.
En outre, disons que vous disposez des autorisations root. Et disons que vous voulez prétendre qu'un fichier doit avoir un accès en lecture uniquement à la racine. Donc, vous Sudo, changez en fait le propriétaire du fichier et les autorisations en root, vous sortez du shell root et essayez de tout emballer. Vous échouez car vous ne pouvez plus lire le fichier car vous ne disposez pas d'un accès root. Vous devez donc Sudo et compresser et construire le package en tant que root. En effet, vous devez tout faire en tant que root.
C'est mauvaisTM.
En tant que packager, vous n'avez pas besoin des autorisations root et vous ne devriez pas l'obtenir. Lorsque vous installez un package, vous devrez peut-être installer un fichier (A) en tant que root et c'est là que vous avez besoin des autorisations root. Tout ce que fakeroot fait est de rendre cela possible. Il permet au packager de répertorier A comme appartenant à root pour l'archiveur, de sorte que lorsque le package est décompressé par l'utilisateur, l'archiveur demande l'autorisation root et crée A comme appartenant à root.
AFAIK, fakeroot exécute une commande dans un environnement dans lequel il semble avoir des privilèges root pour la manipulation de fichiers. Ceci est utile pour permettre aux utilisateurs de créer des archives (tar, ar, .deb, etc.) avec des fichiers avec des autorisations/propriété root. Sans fakeroot, il faudrait avoir les privilèges root pour créer les fichiers constitutifs des archives avec les autorisations et la propriété correctes, puis les emballer, ou il faudrait construire les archives directement, sans utiliser l'archiveur.
fakeroot fonctionne en remplaçant les fonctions de bibliothèque de manipulation de fichiers (chmod (), stat () etc.) par celles qui simulent l'effet qu'auraient eu les fonctions réelles de la bibliothèque, si l'utilisateur avait vraiment é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 exécutant le script ait un accès au niveau racine, mais le script devait encore générer, disons, un fichier tar contenant des fichiers appartenant à root. La façon la plus simple de le faire était d'exécuter le script de construction de paquets sous fakeroot, ce qui a fait croire à l'archiveur que les fichiers appartenaient à root, et les a emballés en tant que tels à l'intérieur de l'archive. De cette façon, lorsque le package a été décompressé sur la machine de destination (sur une autre machine tout à fait), les fichiers n'appartenaient pas à des utilisateurs étranges ou inexistants.
En y réfléchissant, le seul endroit où j'ai vu cela était pour construire une sorte d'archive: rootfs de systèmes embarqués, archives tar.gz, packages rpm, packages .deb, etc.
Une utilisation courante consiste à découvrir à quels fichiers un binaire défaillant voulait vraiment accéder. Autrement dit, trouver et corriger ou contourner les bogues causés par des chemins codés en dur et une gestion des exceptions incorrecte.
La réponse simple:
su et Sudo exécutent les commandes en tant que root. fakeroot ne le fait pas, en dehors de son agencement partiel de bac à sable.
Vous pouvez utiliser fakeroot sans avoir réellement les privilèges root. Si vous aviez su et/ou Sudo vous seriez en mesure de détruire votre système avec un simple rm -rf /, mais avec fakeroot tout au plus vous supprimeriez votre répertoire personnel.