make[1]: Leaving directory `/tmp/portage/tar-1.14/work/tar-1.14' --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-app-arch_-_tar-1.14-24309.log" unlink: /usr/lib64/cf24327/conftest9012345 unlink: /usr/lib64/cf24327/conftest9012346 -------------------------------------------------------------------------------- Reproducable here and on lv's box; tar won't finish building.
Created attachment 37289 [details] tar.log log of the tar emerge
Created attachment 37298 [details, diff] Patch for tar-1.14 with USE=hardened to avoid sandbox violations Attached Patch works for me. Lv would you put it in conditionally for hardened ?
this problem will exist for any profile that doesnt disable sandbox, it's just a coincidence that for amd64 the hardened profiles are the only ones that dont disable it. when we have multilib worked out and can be sure a 32bit sandbox exists, this problem will exist for -all- amd64 profiles. base-system peoples: i hate sandbox and this violation seems to occur with large chunks of system with the lib64. what do i do? force an autoreconf? a patch against configure can be borked at any time.
this error should only occur when using the new 2.3.4.20040808 glibc on amd64. it not only doesnt apply the hack the crams everything into /lib, it makes lib64 a real directory. so... it seems that the test tries to see if lib is a directory. now where i'm confused is how the hell doesnt this cause a similar access violation for /usr/lib? is there already logic in place somewhere that prevents this from happening? and if so, can we add lib64 to it?
just to clear things up a bit, simply moving lib64 to lib and making lib64 a symlink again gets rid of this access violation (semi-dangerous and i wouldnt suggest any users do this, instead disable sandbox for now).
from sandbox.c: strcat(sandbox_write_var, "/usr/lib/cf"); and: strcat(sandbox_write_var, "/usr/lib/conftest"); thanks a million to ferringb for pointing that out.
With profile.bashrc support, this can be corrected in .51. Either profile.bashrc support needs to be backported to .50, or .50 needs it's sandbox modified. Not much for the latter, since I don't like /usr/lib/conftest being a default exception anyways... If a .50 release is coming up, I'll make sure a fix is in. No gurantees on an eta for .50 though.
the fix has made it into 2.9.51_pre... will it show up in 2.0.50?
.50-r10 is out, afaik it contains the sandbox additions to correct this. .51_pre18 and above should have it also.
