On Sun, 20 Mar 2011 at 18:46:12 +0000, Daniel Drake <d...@laptop.org> wrote: > On 20 March 2011 18:05, C. Scott Ananian <csc...@laptop.org> wrote: > so fakeroot (at least debian/unstable's version of fakeroot) should be > able to handle this just fine. > > You're right, this should work. > > But it doesn't, even with fakeroot 1.14.5. > > Test case: > > As root: > mkdir test > echo closed > test/closed > chmod 000 test/closed > tar -cf test.tar test > rm -rf test > > As user: > fakeroot > tar -xpf test.tar > ls -l test/closed > cat test/closed > > Last command gives error. > > > Now exit from the fakeroot and: > ls -l test/closed > > The 000 permissions somehow fell through onto the real filesystem, but > in your more simplistic testcase the 000 permissions stayed only > within the fake environment of fakeroot. > > So..tar must be doing something different from chmod when applying > permissions.
A quick strace with fakeroot-1.14.5-2 and tar-1.25-3 on Debian Squeeze suggests that tar is running something like: umask(022) = 0 umask(0) = 022 mkdirat(AT_FDCWD, "test", 0700) = 0 newfstatat(AT_FDCWD, "test", {st_mode=S_IFDIR|0700, st_size=4096, ...}, 0) = 0 openat(AT_FDCWD, "test/closed", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0) = 4 write(4, "closed\n", 7) = 7 dup2(4, 4) = 4 fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0 utimensat(4, NULL, {{1300653754, 616972565}, {1300653712, 0}}, 0) = 0 fstat(4, {st_mode=S_IFREG, st_size=7, ...}) = 0 fchown(4, 0, 0) = -1 EPERM (Operation not permitted) close(4) = 0 ...and, sure enough, we have a bug [1] entitled "fakeroot: handle openat() and friends". Regards, Michael [1]: http://bugs.debian.org/402688 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel