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?
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 need
fakeroot.) That’s the whole point of
fakeroot: 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, or
install -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 subsequent
tar runs for example to store files as owned by root.
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?
fakeroot doesn’t trick
tar 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 need
fakeroot to produce a tarball containing a file owned by root and suid; if you have a binary
tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, as a regular user, will create a tarball containing
evilbinary, 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):
- install files, owned by root
- archive those files, still owned by root, so that when they’re extracted, they’ll be owned by root
The first part obviously fails if you’re not root. However, when running under
fakeroot, as a normal user, the process becomes
- install files, owned by root — this fails, but
fakeroot pretends it succeeds, and remembers the changed ownership
- archive those files, still owned by root — when
tar (or whatever archiver is being used) asks the system what the file ownership is,
fakeroot changes the answer to match the ownership it recorded earlier
Thus 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 by
dpkg directly with the
Rules-Requires-Root directive (see
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:
- build the software (which can be done without privileges)
- install the software (which needs to be done as root, or at least as a user allowed to write to the appropriate system locations)
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:
- build the software (with no special privileges)
- pretend to install the software (again with no special privileges)
- capture the software installation as a package (ditto)
- make the package available (ditto)
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.