dumb little buglet. Checking ./196.using_froz @ ../doc/m4.texinfo:6843: Origin of test ./196.using_froz: stderr mismatch --- m4-tmp.20265/m4-xerr 2008-10-25 18:07:42.000000000 -0600 +++ m4-tmp.20265/m4-err 2008-10-25 18:07:42.000000000 -0600 @@ -1 +1 @@ -m4: cannot open `/none/such': No such file or directory +m4: cannot open `/none/such': Permission denied FEATURES="-sandbox" passes.
toolchain test failures are a bit discomforting. Same failure here, CC'ing :)
should be fixed with sandbox-1.3.0
sorry, still getting this with sandbox-1.3.3
i'm pretty sure the original reason for this failure has been fixed. what is happening now is that the code tries to do a writable open() on /none/such and since / is in the deny path, we flag this as a sandbox violation and set the error to EACCES. in other words, this behavior is currently by design and not a bug like the original report (where errno was not saved/restored). i'm thinking if we change sandbox so that if it tries to do an open() on a predicted path where the leading paths are missing, we just let it through ... then we'd have to update the m4 ebuild to add a predict on the /none/ dir. and add a check to make sure /none/ doesnt actually exist ;).
hmm, doesnt need predict by default actually since we dont setup everything as deny by default http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=1001c5ed6854cad1bf52b8b59e3a1a084600b8c6
looks like the environment portage sets up by default didnt let that fix do its magic. should be ok though for sandbox 1.3.6. http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=commitdiff;h=0f7ed37fdc1d7c98328536db372ec6b7a49c0d5e
*** Bug 259184 has been marked as a duplicate of this bug. ***
By pure chance, I stumbled on Bug 259184 today, and decided that it is enough of a potential pitfall that upstream should indeed worry about it. I've applied this patch upstream: http://git.savannah.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=70c9e6ea so that m4 1.4.13 will not care about the difference between ENOENT and EACCES on this particular test. Would you mind giving it a try?
well, the issue here wasnt that the system was returning EACCESS ... there was a bug in our sandbox code which was corrupting errno in error conditions and it just happened to leave EACCESS in the errno when returning for m4 here. but in general, the change you made shouldnt cause a problem for people ...
*** Bug 263926 has been marked as a duplicate of this bug. ***
I don't think that's a valid fix, e.g. it breaks on mkdir /none touch /none/such (And clever folks will notice that you get EACCESS if you chmod 0 /none) The test should be changed to look in ./none/such (assuming its CWD is sensible) or somesuch, which we can sanely expect to never exist unless someone's fiddling with the build dir (in which case all bets are off).
you're going to have to provide real details for what problems you're seeing current behavior: src_test: mkdir /none -> EPERM, chmod 0 /none -> ENOENT any other src_*: sandbox aborts throwing a violation both of those look correct to me
I mean the precondition "/none exists" would fail the original test anyway, e.g. any of mkdir /none; touch /none/such; chmod 777 /none/such mkdir /none; ln -s /dev/null /none/such ln -s /tmp /none I don't think that a test should rely on the non-existence of something completely outside its control. I don't think that a sandbox should fudge some error codes just to keep some (broken) tests happy. I don't think that [[ -d /none ]] && die is a fix. In fact, 128.include already relies on the nonexistence of checks/none (it does include(`none')). Changing 196.using_froz to use ./none/such instead of /none/such seems like a far more sensible solution than everything else that seems to have been done to "fix" this bug, if only because it's a 3-byte change to the code that's broken.
m4 isnt the only test to make this assumption. we can either try and go around and change code that realistically works everywhere else, or make sandbox a bit smarter. it isnt fudging errors here, it's looking at function calls and letting through ones that are known to fail ahead of time. like `touch /none/such` when /none/ doesnt exist. read the commits i posted.