Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 244396 - sys-devel/m4-1.4.12 fails 196.using_froz due to sandbox changing errno
Summary: sys-devel/m4-1.4.12 fails 196.using_froz due to sandbox changing errno
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Sandbox Maintainers
URL:
Whiteboard:
Keywords:
: 259184 263926 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-26 00:18 UTC by Ryan Hill (RETIRED)
Modified: 2010-02-09 05:24 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hill (RETIRED) gentoo-dev 2008-10-26 00:18:44 UTC
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.
Comment 1 Mart Raudsepp gentoo-dev 2008-11-15 18:39:30 UTC
toolchain test failures are a bit discomforting. Same failure here, CC'ing :)
Comment 2 SpanKY gentoo-dev 2008-11-16 13:42:25 UTC
should be fixed with sandbox-1.3.0
Comment 3 Ryan Hill (RETIRED) gentoo-dev 2009-02-02 05:12:30 UTC
sorry, still getting this with sandbox-1.3.3
Comment 4 SpanKY gentoo-dev 2009-02-02 06:25:30 UTC
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 ;).
Comment 5 SpanKY gentoo-dev 2009-02-02 07:13:16 UTC
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
Comment 6 SpanKY gentoo-dev 2009-02-08 03:43:36 UTC
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
Comment 7 SpanKY gentoo-dev 2009-02-17 00:29:39 UTC
*** Bug 259184 has been marked as a duplicate of this bug. ***
Comment 8 Eric Blake 2009-02-17 03:58:52 UTC
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?
Comment 9 SpanKY gentoo-dev 2009-02-17 04:05:55 UTC
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 ...
Comment 10 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2009-03-28 08:28:00 UTC
*** Bug 263926 has been marked as a duplicate of this bug. ***
Comment 11 T Chan 2010-02-09 00:29:46 UTC
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).
Comment 12 SpanKY gentoo-dev 2010-02-09 01:39:54 UTC
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
Comment 13 T Chan 2010-02-09 04:59:07 UTC
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.
Comment 14 SpanKY gentoo-dev 2010-02-09 05:24:48 UTC
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.