.\" Process this file with
.\" groff -man -Tascii foo.1
.\"
.\" "verbatim" environment (from strace.1)
.de CW
.sp
.nf
.ft CW
..
.de CE
.ft
.fi
.sp
..
.\"
.TH fakeroot 1 "26 July 1997" "Debian Project" "Debian GNU/Linux manual"
.\" Manpage by J.H.M. Dassen <jdassen@wi.LeidenUniv.nl>
.SH NAME
fakeroot \- run a command in an environment faking root privileges for file
manipulation
.SH SYNOPSIS
.B fakeroot 
.BI [ command ]
.B [\-d] [\-c
.IB command ] 
.B [\-\-lib
.IB library ] 
.B [\-\-mixedlibhack] [\-\-nomixedlibhack] [\-\-debian]
.SH DESCRIPTION
.B fakeroot
runs a command in an environment were 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 
.B fakeroot
one would have 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.

.B fakeroot
works by replacing the file manipulation library functions (chmod(2),
stat(2) etc.) by ones that simulate the effect the real library
functions would have had, had the user really been root. These wrapper
functions are in a shared library
.B /usr/lib/libfakeroot.so*
which is loaded through the 
.B LD_PRELOAD
mechanism of the dynamic loader.
.\" ref. to documentation?

If you intend to build packages with 
.BR fakeroot ,
please try building
fakeroot first: the "debian/rules build" stage has a
few tests (testing mostly for previous bugs in old fakeroot
versions). If those tests fail (for example because you have
certain libc5 programs on your system), other packages you build with
fakeroot will quite likely fail too, but possibly in much more subtle
ways.

Also, note that it's best not to do the building of the binaries
themselves under fakeroot. Especially configure and friends don't like
it when the system suddenly behaves differently from what they
expect. (or, thyy unset some environemnt variables, that cause
problems with fakeroot).


.SH OPTIONS
.TP
.B \-d
Print debugging information on stderr.
.TP
.BI \-c \ command
Specify the command to execute in the "fakeroot" environment.
.TP
.BI \-\-lib \ library
Specify an alternative wrapper library.
.TP
.B \-\-mixed-libhack
Test for libc5 binaries, and remove 
.B LD_PRELOAD 
for them.
.TP 
.B \-\-nomixedlibhack
Do not test for libc5 binaries. (This makes 
.B fakeroot 
significantly faster).
.TP
.B \-\-debian
According to the Debian Policy Manual section 3.3.8,
no files should be unreadable by anyone
on the system (mode 644 is a minimum), and directories should have
mode 755 or 2775. With this option, when a program running inside
.B fakeroot 
tries to violate these rules, the wrapper functions return
-1, and set errno to
.BR EPERM .
By default (or with the
.B \-\-nodebian
option), this checking isn't done.
.SH EXAMPLES
Here is an example session with 
.BR fakeroot . 
Notice that inside the fake root environment file manipulation that
requires root privileges succeeds, but is not really happening.
.CW
rulcmc:/tmp/joost$  whoami
joost
rulcmc:/tmp/joost$ fakeroot /bin/bash
rulcmc:/tmp/joost$  whoami
root
rulcmc:/tmp/joost# mknod hda3 b 3 1
rulcmc:/tmp/joost# ls -ld hda3
brw-r--r--   1 root     root       3,   1 Jul  2 22:58 hda3
rulcmc:/tmp/joost# chown joost:root hda3
rulcmc:/tmp/joost# ls -ld hda3
brw-r--r--   1 joost    root       3,   1 Jul  2 22:58 hda3
rulcmc:/tmp/joost# ls -ld /
drwxr-xr-x  20 root     root         1024 Jun 17 21:50 /
rulcmc:/tmp/joost# chown joost:users /
rulcmc:/tmp/joost# chmod a+w /
rulcmc:/tmp/joost# ls -ld /
drwxrwxrwx  20 joost    users        1024 Jun 17 21:50 /
rulcmc:/tmp/joost# exit
rulcmc:/tmp/joost$ ls -ld /
drwxr-xr-x  20 root     root         1024 Jun 17 21:50 //
rulcmc:/tmp/joost$ ls -ld hda3
-rw-r--r--   1 joost    users           0 Jul  2 22:58 hda3
.CE
Only the effects that user
.B joost
could do anyway happen for real. 

.B fakeroot
was specifically written to enable users to create Debian GNU/Linux 
packages (in the 
.BR deb(5)
format) without giving them root privileges.
This can be done by commands like
.B dpkg-buildpackage -rfakeroot
or
.B build -rfakeroot
.SH SECURITY ASPECTS
.B fakeroot
is a regular, non-setuid program. It does not enhance a user's
privileges, or decrease the system's security.
.SH FILES
.I /usr/lib/libfakeroot.so*
The shared library containing the wrapper functions.
.SH ENVIRONMENT
.B 
.IP FAKEROOTKEY
The key used to communicate with the fakeroot daemon. Any program
started with the right 
.B LD_PRELOAD
and a
.B FAKEROOTKEY
of a running daemon will automatically connect to that daemon, and
have the same "fake" view of the filesystem's permissions/ownerships.
(assuming the daemon and connecting program were started by the same
user). 
.SH LIMITATIONS
.B
.IP "Library versions"
Every command executed within 
.B fakeroot 
needs to be linked to the same version of the C library as
.B fakeroot
itself. By default, before executing a command, fakeroot checks
what C library it uses, and drops the 
.B LD_PRELOAD
environment variable if the command uses a different library.
This behaviour can be controlled via the  
.BR --nomixedlibhack ,  
.B --mixedlibhack
commandline arguments.
.B
.IP open()/create()
Fakeroot doesn't wrap open(), create(), etc. So, if user
.B joost
does either
.CW
touch foo
fakeroot 
ls -al foo
.CE
or the other way around,
.CW
fakeroot
touch foo
ls -al foo
.CE
fakeroot has no way of knowing that in the first case, the owner of
foo really should be
.B joost
while the second case it should have been
.BR root .
For the Debian packaging, defaulting to giving all "unknown" files
uid=gid=0, is always OK. The real way around this is to wrap
.B open() 
and 
.BR create() , 
.B
.IP "debian policy checking"
When using the 
.B --debian 
option, 
.B fakeroot
checks if you follow the debian policy rules. It does so
slightly too strict though: doing "chmod a-r foo; chmod a+r foo" in
your debian/rules binary would not be against the letter of the debian
policy, but the first command does return EPERM. If you know of any
real-life situations where this is a problem, please tell me.
.B
.IP "Speed"
Mostly due to the mixed-libc-hack, exec*(2,3)-ing  processes under
.B fakeroot
is significantly slower than when running with real-root
privileges. For example, the build-time-tests in the source code take
on my machine about 8s when run with 
.B fakeroot
with the mixedlibc hack. When turning off the mixedlibc hack, or using
real root privileges, this goes down to less than 2s. Note that
for most packages, the "debian/rules build" process takes the longest,
and this shouldn't be done with fakeroot anyway.
.B
.IP "GNU configure (and other such programs)"
Fakeroot, in effect, is changing the way the system
behaves. Programs that probe the system like GNU configure may get
confused by this (or if they don't, they may stress fakeroot so much
that fakeroot itself becomes confused). So, it's advisable not to run
"configure" from within fakeroot. As configure should be called in the
"debian/rules build" target, running "dpkg-buildpackage -rfakeroot"
correctly takes care of this.
.SH BUGS
None so far. Be warned, though: although I've written quite a few much
larger (and smaller) programs, I've never written anything that was
as tiny as
.BR fakeroot ,
had as many bugs as
.BR fakeroot ,
and still was as usable as, say, 
.BR fakeroot
version 0.0_3, the first version that could be used to build itself.
.SH COPYING
.B fakeroot
is distributed under the GNU General Public License.
(GPL 2.0 or greater).
.SH AUTHOR
joost witteveen
.RI < joostje@debian.org >
.SH MANUAL PAGE
mostly by J.H.M. Dassen 
.RI <jdassen@wi.LeidenUniv.nl> 
Some mods/additions by joost.
.SH "SEE ALSO"
.BR dpkg-buildpackage (1),
.BR build (1L)