Problem
Your issue has to do with permission inheritance. cdbootstrap will inherit the permissions of fakeroot, which can be elevated via sudo. Issue:
sudo fakeroot cdbootstrap /tmp/foo
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).
Better Solution
Instead of using privilege escalation to achieve what you're trying to do consider using a proper chroot, as outlined in the DebootstrapChroot Documentation for Ubuntu, or the Official Debian Documentation for DebBootStrap.
ls -al /tmp/foo? – eyoung100 Jul 29 '15 at 22:18/tmp/foo/var/cache/bootstrap/, and their permissions are set to 644 to my user. – Florian Margaine Jul 29 '15 at 22:22sudo fakerootIt's the fakeroot that isn't permissioned right...? – eyoung100 Jul 29 '15 at 22:37sudo fakerootdoes work. – Florian Margaine Jul 29 '15 at 22:43