Return to Answer

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has its own issues. From the man page:

LIMITATIONS

   Library versions
          Every command executed within fakeroot needs to be linked to the
          same version of the C library as fakeroot itself.

   open()/create()
          fakeroot  doesn't  wrap open(), create(), etc. So, if user joost
          does either

          touch foo
          fakeroot
          ls -al foo

          or the other way around,

          fakeroot
          touch foo
          ls -al foo

          fakeroot has no way of knowing that in the first case, the owner
          of  foo  really  should be joost while the second case it should
          have been 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 open() and  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
          fakeroot .  It turned out that a minor upgrade of libc (from one
          where the stat() function didn't use open() to one with a stat()
          function that did (in some cases) use open()), would cause unex-
          plainable segfaults  (that  is,  the  libc6  stat()  called  the
          wrapped  open(),  which  would then call the libc6 stat(), etc).
          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 fake-
          root as small as possible, to limit the  likelihood  of  'colli-
          sions'.

   GNU configure (and other such programs)
   of the file will be 000. The bug is that if root does the same,  open()
   will succeed, 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  func-
   tions slightly change).

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has its own issues. From the man page:

LIMITATIONS

Library versions

Every command executed within fakeroot needs to be linked to the same version of the C library as fakeroot itself.

open()/create()

fakeroot doesn't wrap open(), create(), etc. So, if user joost does either

  touch foo
  fakeroot
  ls -al foo

or the other way around,

  fakeroot
  touch foo
  ls -al foo

fakeroot has no way of knowing that in the first case, the owner
of foo really should be joost while the second case it should
have been 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 open() and 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
fakeroot . It turned out that a minor upgrade of libc (from one
where the stat() function didn't use open() to one with a stat() function that did (in some cases) use open()), would cause unexplainable segfaults (that is, the libc6 stat() called the wrapped open(), which would then call the libc6 stat(), etc).
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 likelihood of 'collisions'.

BUGS

It doesn'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, open() will succeed, 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).

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has it's own issues. From the man page:

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has its own issues. From the man page:

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has it's own issues. From the man page:

If the above command succeeds, permissions on /tmp are the issue. See What are common rights for /tmp ? I unintentionnally set it all public recursively, for what the default permissions should be. Generally, writing anything into /tmp that wasn't put there by an application is a bad idea, and fakeroot has it's own issues. From the man page: