When logging an error, write_logfile() will copy a string with strndup() and free() it later. As the libc strndup() won't use our own malloc(), free() will fail, printing an error message and not actually freeing the memory. Reproducible: Always Steps to Reproduce: $ sandbox touch / Actual Results: ACCESS DENIED open_wr: / sandbox memory corruption free(0x08ce9968): Invalid argument /usr/lib/libsandbox.so[0xb7f94d61] /usr/lib/libsandbox.so[0xb7f93d76] /usr/lib/libsandbox.so[0xb7f949c0] /usr/lib/libsandbox.so[0xb7f94c3d] /usr/lib/libsandbox.so(open64+0x6f)[0xb7f9668e] touch[0x804db0b] touch[0x80497d2] /lib/libc.so.6(__libc_start_main+0xe2)[0xb7e56622] touch[0x8048e51] ACCESS DENIED utimensat: / sandbox memory corruption free(0x08ce9d60): Invalid argument /usr/lib/libsandbox.so[0xb7f94d61] /usr/lib/libsandbox.so[0xb7f93d76] /usr/lib/libsandbox.so[0xb7f949c0] /usr/lib/libsandbox.so(utimensat+0x31)[0xb7f951ae] touch[0x804d74d] touch[0x804961f] /lib/libc.so.6(__libc_start_main+0xe2)[0xb7e56622] touch[0x8048e51] touch: cannot touch `/': Permission denied --------------------------- ACCESS VIOLATION SUMMARY --------------------------- [...] Expected Results: ACCESS DENIED open_wr: / ACCESS DENIED utimensat: / touch: cannot touch `/': Permission denied --------------------------- ACCESS VIOLATION SUMMARY --------------------------- [...] Patch follows.
Created attachment 180504 [details, diff] We always need our own strndup()
Remark: Why are you using xcalloc/xmalloc in calloc/realloc/strdup? Isn't that backwards? It makes xcalloc/xrealloc/xstrdup bogus, as those then check for things that can't happen.
Created attachment 180505 [details, diff] calloc/realloc/strdup: Don't use xzalloc/xmalloc Attaching a patch regarding comment #2, in case you agree with me. :)
better to avoid all the weird overhead in the first place (and thus avoid strndup propagation). thanks for the patches though and tracking this down ... i had noticed there was an issue, but hadnt looked into what was causing it. http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=6b0d80b98ba7da7facd9b4be901905fe25516d11
Plese, don't close the bug until it's fixed in tree.
i track git. fixes will propagate into the tree eventually. the bug in question isnt a big deal and doesnt break any code that isnt already broken.
*** Bug 257488 has been marked as a duplicate of this bug. ***
*** Bug 257116 has been marked as a duplicate of this bug. ***
Are these real duplicates?
*** Bug 257701 has been marked as a duplicate of this bug. ***
Is there a fix yet for the py object problem itself? How is it related to this sandbox problem?
those are not duplicates. this issue is about the display problem and nothing else. stop duping/re-opening.
(In reply to comment #12) > stop duping/re-opening. Sorry, but that's completely nonsensical.
no it isnt. this bug has nothing to do with .py/.pyc sandbox violations. marking those as dupes of this or re-opening this bug is wrong.
Comment on attachment 180505 [details, diff] calloc/realloc/strdup: Don't use xzalloc/xmalloc sorry, i'd forgotten about this one ... ive applied this fix in git now, thanks http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=541bbacc5a7b5f2f98ce9b64d05b8e3bb94ca211
