After reading some pretty nice answers from this question, I am still fuzzy on why you would want to pretend that you are root without getting any of the benefits of actually being root.
So far, what I can gather is that fakeroot is used to give ownership to a file that needs to be root when it is unzip/tar'ed. My question, is why can't you just do that with chown?
A Google Groups discussion here points out that you need fakeroot to compile a Debian kernel (if you want to do it from an unprivileged user). My comment is that, the reason you need to be root in order to compile is probably because read permissions were not set for other users. If so isn't it a security violation that fakeroot allows for compilation(which means gcc can now read a file that was for root)?
This answer here describes that the actual system calls are made with real uid/gid of the user, so again where does fakeroot help?
How does fakeroot stop unwanted privilege escalations on Linux? If fakeroot can trick tar into making a file that was owned by root, why not do something similar with SUID?
From what I have gathered, fakeroot is just useful when you want to change the owner of any package files that you built to root. But you can do that with chown, so where am I lacking in my understanding of how this component is suppose to be used?
Best Answer
Because you can’t just do that with
chown
, at least not as a non-root user. (And if you’re running as root, you don’t needfakeroot
.) That’s the whole point offakeroot
: to allow programs which expect to be run as root to run as a normal user, while pretending that the root-requiring operations succeed.This is used typically when building a package, so that the installation process of the package being installed can proceed without error (even if it runs
chown root:root
, orinstall -o root
, etc.).fakeroot
remembers the fake ownership which it pretended to give files, so subsequent operations looking at the ownership see this instead of the real one; this allows subsequenttar
runs for example to store files as owned by root.fakeroot
doesn’t tricktar
into doing anything, it preserves changes the build wants to make without letting those changes take effect on the system hosting the build. You don’t needfakeroot
to produce a tarball containing a file owned by root and suid; if you have a binaryevilbinary
, runningtar cf evil.tar --mode=4755 --owner=root --group=root evilbinary
, as a regular user, will create a tarball containingevilbinary
, owned by root, and suid. However, you won’t be able to extract that tarball and preserve those permissions unless you do so as root: there is no privilege escalation here.fakeroot
is a privilege de-escalation tool: it allows you to run a build as a regular user, while preserving the effects the build would have had if it had been run as root, allowing those effects to be replayed later. Applying the effects “for real” always requires root privileges;fakeroot
doesn’t provide any method of acquiring them.To understand the use of
fakeroot
in more detail, consider that a typical distribution build involves the following operations (among many others):The first part obviously fails if you’re not root. However, when running under
fakeroot
, as a normal user, the process becomesfakeroot
pretends it succeeds, and remembers the changed ownershiptar
(or whatever archiver is being used) asks the system what the file ownership is,fakeroot
changes the answer to match the ownership it recorded earlierThus you can run a package build without being root, while obtaining the same results you’d get if you were really running as root. Using
fakeroot
is safer: the system still can’t do anything your user can’t do, so a rogue installation process can’t damage your system (beyond touching your files).In Debian, the build tools have been improved so as not to require this any more, and you can build packages without
fakeroot
. This is supported bydpkg
directly with theRules-Requires-Root
directive (seerootless-builds.txt
).To understand the purpose of
fakeroot
, and the security aspects of running as root or not, it might help to consider the purpose of packaging. When you install a piece of software from source, for use system-wide, you proceed as follows:When you package a piece of software, you’re delaying the second part; but to do so successfully, you still need to “install” the software, into the package rather than onto the system. So when you package software, the process becomes:
Now a user completes the process by installing the package, which needs to be done as root (or again, a user with the appropriate privileges to write to the appropriate locations). This is where the delayed privileged process is realised, and is the only part of the process which needs special privileges.
fakeroot
helps with steps 2 and 3 above by allowing us to run software installation processes, and capture their behaviour, without running as root.