mjhjmtu

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?

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 evilbinary, running 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 rootless-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:

1. build the software (which can be done without privileges)


2. 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:

1. build the software (with no special privileges)


2. pretend to install the software (again with no special privileges)


3. capture the software installation as a package (ditto)


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

NO. Fake root allows you to run permission manipulation and reporting tools, it will report consistently. However it will not actually grant these permissions. It will just look like you have them (fake). It will not change anything outside of the environment.

It is useful, if you want to create a directory structure, that contains ownership and permissions, that could not be set by your user, that you will then tar, zip, or other package.

It does not really elevate permissions, it is fake. It does not let you do anything (delete, write, read) that you could not otherwise do. You could produce the package (in theory) without it. You could get a fake report (ls) without it.

It is not a security flaw, because it does not allow access, or anything that you can't do without it. It runs without privilege. All it dose is intercept calls to chown, chmod, etc. It makes them a no-operation, except that it records what would have happened. It also intercepts calls to stat etc. so that it reports permissions and ownership, from its own internal database, as if the other commands had been done. This is useful, because if you then zip the directory, it will have the fake permissions. If you then unzip, as root, then the permissions will become real.

Any files that are not readable/writable before, will remain not readable/writable. Any special files (e.g. devices) created, will have no special powers. Any set-uid (to another user), files will not set-uid. Any other privilege escalation will not work.

It is a type of virtual machine: A virtual machine, in general, can simulate any environment/OS, but can not do anything to the host, that any other application could not do. Within the Virtual machine, you can appear to do anything. You can reinvent the security system to be the same or different, However this will all exist on the host, as resources owned by the user/group of the process running the virtual environment.

There are already two good, and very detailed answers here, but I'll just point out that the introductory paragraph of the original fakeroot man page¹ actually explains it pretty clearly and concisely:

fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver.

Fakeroot allows a non-root user to create archives containing root-owned files, which is a critical part of generating and distributing binary software packages in Linux. Without fakeroot, package archives would have to be generated while running as actual root, so that they contain the correct file ownership and permissions. That would be a security risk. Building and packaging potentially-untrusted software is a huge exposure if done with root privs. Thanks to fakeroot, an unprivileged user with unprivileged files can still generate archives containing files with root ownership.²

But it's not a security risk, because nothing in the archive is actually owned by root until the files are EXTRACTED. And even then, the files will only be extracted with their root permissions intact if it's done by a privileged user. That step — where a fakeroot-assisted archive containing "root" files is extracted by a privileged user — is where the "fake" root finally becomes real. Up until that point, no actual root privileges are ever obtained or bypassed.

Notes

1. Fakeroot has spawned some competitors/imitators that will masquerade as fakeroot if installed, including fakeroot-ng and pseudo. But IMHO neither "imitator's" man page is nearly as clear about getting right to the point on this question. Stick with the original, one and only fakeroot O.G.


2. 
   

   Other distros/packaging-systems overcome this by simply not using root ownership in their package archives. On Fedora, for instance, software can be compiled, installed, and packaged by an unprivileged user without requiring fakeroot. It's all done within the user's $HOME/rpmbuild/ space, and normally-privileged steps like make install get redirected (via mechanisms like --prefix and DESTDIR) to a $HOME/rpmbuild/BUILDROOT/ hierarchy that could be considered a sort of "fakechroot" space (without actually using fakechroot).

   
   
   

   But even during make install, everything is executed as and owned by the
   unprivileged user. Extracted file ownership and permissions will be set to root,root and 0644 (or 0755 for executables) by default, unless overridden in the package definition (.spec) file in which case they're stored as metadata within the final package.
   Because no permissions or ownership are actually applied until the rpm package's (privileged)
   installation process, neither root nor fakeroot is needed during packaging. But fakeroot is really just a different
   path to that same result.