Subject: Re: make update hell
To: Ben Collver <>
From: Pavel Cahyna <>
List: tech-pkg
Date: 10/08/2004 16:11:14
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> On Fri, Oct 08, 2004 at 03:27:19PM +0200, Pavel Cahyna wrote:
> > OpenBSD ports and Debian can do it, AFAIK by "installing" to some
> > temporary directory. I don't know if it would work on HP-UX (but why not?)
> Assuming that they are "installing" as a non-root user, how do they get
> setuid executables for the GNU Screen package?

For Debian: man fakeroot

(attached for your convenience)

For OpenBSD: no idea. Maybe I was wrong with that one. But making a binary
packages without doing the "real" install would be useful, even if it
would have to be done as root. I'm sure (almost) that OpenBSD can do it
(not so sure if they require root or not.)

How does " -U sets" get setuid executables for packaging NetBSD?


Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="fakeroot.1"

.\" Process this file with
.\" groff -man -Tascii foo.1
.\" "verbatim" environment (from strace.1)
.de CW
.ft CW
.de CE
.TH fakeroot 1 "26 July 1997" "Debian Project" "Debian GNU/Linux manual"
.\" Manpage by J.H.M. Dassen <>
fakeroot \- run a command in an environment faking root privileges for file
.B fakeroot 
.B [\-l|\-\-lib
.IB library] 
.B [-\-faked
.IB faked-binary] 
.BI [--]
.BI [command]
.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.
.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

.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/*
which is loaded through the 
mechanism of the dynamic loader. (See
.BR (8))

If you intend to build packages with 
.BR fakeroot ,
please try building
the fakeroot package first: the "debian/rules build" stage has a
few tests (testing mostly for 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

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, they randomly unset some environemnt variables, some of
which fakeroot needs).

.BI \-\-lib \ library
Specify an alternative wrapper library.
.BI \-\-faked \ binary
Specify an alternative binary to use as faked.
.BI [\-\-] \ command
any command you want to be ran as fakeroot. Use `--' if in the command
you have other options that may confuse fakeroot's option parsing.
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.
$  whoami
$ fakeroot /bin/bash
#  whoami
# mknod hda3 b 3 1
# ls -ld hda3
brw-r--r--   1 root     root       3,   1 Jul  2 22:58 hda3
# chown joost:root hda3
# ls -ld hda3
brw-r--r--   1 joost    root       3,   1 Jul  2 22:58 hda3
# ls -ld /
drwxr-xr-x  20 root     root         1024 Jun 17 21:50 /
# chown joost:users /
# chmod a+w /
# ls -ld /
drwxrwxrwx  20 joost    users        1024 Jun 17 21:50 /
# exit
$ ls -ld /
drwxr-xr-x  20 root     root         1024 Jun 17 21:50 //
$ ls -ld hda3
-rw-r--r--   1 joost    users           0 Jul  2 22:58 hda3
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
.B debuild -rfakeroot
(actually, -rfakeroot is default in debuild nowadays, so you don't
need that argument).
.B fakeroot
is a regular, non-setuid program. It does not enhance a user's
privileges, or decrease the system's security.
.I /usr/lib/libfakeroot/*
The shared library containing the wrapper functions.
The key used to communicate with the fakeroot daemon. Any program
started with the right 
and a
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
.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. Because the potato version of debian now uses libc6 only
(glibc2.1), this isn't that much of a problem any more. 
.IP open()/create()
Fakeroot doesn't wrap open(), create(), etc. So, if user
.B joost
does either
touch foo
ls -al foo
or the other way around,
touch foo
ls -al foo
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() 
.BR create() ,
but that creates other problems, as demonstrated by the libtricks
package. This package wrapped many more functions, and tried to do a
lot more than
.B fakeroot.
It turned out that a minor upgrade of libc (from one where the 
.BR stat()
function didn't use
.BR open()
to one with a
.BR stat()
function that did (in some cases) use
.BR open() ),
would cause unexplainable segfaults (that is, the libc6 
.BR stat()
called the wrapped
.BR open() ,
which would then call the libc6
.BR stat() ,
. Fixing them wasn't all that easy,
but once fixed, it was just a matter of time before another function
started to use open(), never mind trying to port it to a different
operating system. Thus I decided to keep the number of functions
wrapped by fakeroot as small as possible, to limit the likelyhood
of `collisions'.
.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.
It doens't wrap open(). This isn't bad by itself, but if a program
does open("file", O_WRONLY, 000), writes to file "file", closes it,
and then again tries to open to read the file, then that open fails, as
the mode of the file will be 000. The bug is that if root does the
same, the open will suceed, as the file permissions aren't checked at
all for root. I choose not to wrap open(), as open() is used by many
other functions in libc (also those that are already wrapped), thus
creating loops (or possible future loops, when the implementation of
various libc functions slightly change).
.B fakeroot
is distributed under the GNU General Public License.
(GPL 2.0 or greater).
joost witteveen
.RI < >
mostly by J.H.M. Dassen 
.RI <> 
Rather a lot mods/additions by joost.
.BR faked (1)
.BR dpkg-buildpackage (1),
.BR build (1L)
.BR /usr/doc/fakeroot/DEBUG