This is probably related to one of the several bugs filed against sandbox with static apps (bug 264478, bug 280139, and particularly bug 265885), but since it's not precisely the same I figured I'd open a new one. The specific behavior is when /bin/cp calls utimensat() from lib/utimens.c:gl_futimens(), most repeatably when calling 'cp -r --preserve=timestamps' where there are multiple sub-directories containing at least one file to copy. Test case: 1. Obtain static 'cp' executable (sys-apps/coreutils[static] doesn't complete building on amd64). 2. Install >= sys-apps/sandbox-1.7 (1.6 doesn't exhibit this behavior) 3. Perform the following: # cd /var/tmp # mkdir -p t1/foo # mkdir -p t1/bar # mkdir t2 # touch t1/foo/baz # touch t1/bar/baz # sandbox /usr/local/bin/cp -vrp t1 t2 `t1' -> `t2/t1' `t1/foo' -> `t2/t1/foo' `t1/foo/baz' -> `t2/t1/foo/baz' # echo $? 137 The '-v' isn't necessary, but illustrates premature termination after completing the first directory - added debugging statements indicate the call to utimensat() in lib/utimens.c:95 (coreutils-7.6) never returns. For some reason I can't get sandbox to print an access violation now (or even a debug log), but for a while it was consistently indicating './cp' was trying to access '/XX9', where X was a repeated pair of non-ascii characters (obviously junk). Unfortunately, sandbox' use of ptrace prevents my digging any deeper into this in a reasonable timeframe. It was initially discovered while installing sys-libs/db-4.8.24 on a ~x86 hardened system with static coreutils, but I've since reproduced it on an ~amd64 default/linux/amd64/10.0 workstation.
you need to be testing the latest version (2.1). results with older versions isnt interesting.
If I've gone to this level of analysis, it would have been awfully foolish for me to not test against the latest version. # sandbox --version Gentoo path sandbox version: 2.1 C lib: libc.so.6 (/lib64/libc.so.6) build: Sep 29 2009 08:13:06 contact: sandbox@gentoo.org via http://bugs.gentoo.org/ rtld: next is OK! :D schizo: x86_64:-m64 x86:-m32 configured with these options: --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 build_alias=x86_64-pc-linux-gnu host_alias=x86_64-pc-linux-gnu CC= CFLAGS=-march=nocona -O2 -fomit-frame-pointer -pipe LDFLAGS=-Wl,-O1 CPPFLAGS=
not everyone tests things correctly, and comparing the behavior of 1.7 to 2.1 isnt really correct since it's had plenty of fixes
thanks for the analysis. as you point out, the utimensat code was parsing garbage because it skipped one too many function arguments. should be fixed in sandbox-2.2 now. http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=ae95bc8deb1894292a26aea88490ba00f2d68c2a
Confirmed fixed; it's just icing on the cake that you added the tests for it as well. Thanks for going above and beyond!
