root ~# emerge yacc Calculating dependencies ...done! >>> emerge (1 of 1) dev-util/yacc-1.9.1-r2 to / >>> md5 src_uri ;-) yacc-1.9.1.tar.Z >>> Unpacking source... >>> Unpacking yacc-1.9.1.tar.Z to /var/tmp/portage/yacc-1.9.1-r2/work * Applying mkstemp.patch... [ ok ] * Applying yacc-1.9.1-ia64.patch... [ ok ] >>> Source unpacked. rm yacc gcc -O2 -mcpu=i686 -pipe -o yacc closure.c error.c lalr.c lr0.c main.c mkpar.c output.c reader.c skeleton.c symtab.c verbose.c warshall.c >>> Install yacc-1.9.1-r2 into /var/tmp/portage/yacc-1.9.1-r2/image/ category dev-util man: prepallstrip: strip: strip: usr/bin/yacc >>> Completed installing into /var/tmp/portage/yacc-1.9.1-r2/image/ File in security violation (bad owner/group): /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8790.log >>> /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8790.log file mode: r open: No such file or directory root ~# emerge yacc File in security violation (bad owner/group): /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8385.log >>> /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8385.log file mode: r open: No such file or directory aux_get(): (0) Error in dev-util/yacc-1.9.1-r2 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) Calculating dependencies !!! all ebuilds that could satisfy "yacc" have been masked. !!! possible candidates are: - dev-util/yacc-1.9.1-r1 (masked by: ) File in security violation (bad owner/group): /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8409.log >>> /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8409.log file mode: r open: No such file or directory aux_get(): (0) Error in dev-util/yacc-1.9.1-r2 ebuild. (1) Check for syntax error or corruption in the ebuild. (--debug) !!! Error calculating dependencies. Please correct. And right it is, root ~# ls -l /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8409.log ls: /tmp/sandbox-dev-util_-_yacc-1.9.1-r2-8409.log: No such file or directory If I delete /var/tmp/portage/yacc-1.9.1-r2/*, I get the 1st error again. On other occasions it aborts with security violations, "sandbox full: try again later!" or "unlink: /tmp/sandboxpids.tmp" or "you just encountered a sandbox bug: report to http://bugs.gentoo.org" or "general sandbox problem: no sand!" or "sandbox closed for maintenance, try again later!" Downgrading to portage-2.0.50-r1 from a binary package solved it. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Never mind, problem was a unprivileged user process spitting out the right /tmp/foo_._bar-nnnnn.log at the right time and thereby confusing emerge to death. It is undecided whether to remove the offending user from the system or hire him as a security expert. Is it safe to use 2.0.50-r3 or should we stick with 2.0.50-r1 until a better fix is found?
What's wrong with -r3? It detected someone messing around on your system.
Well it did accept 5 out of 8 fake sandbox logs so it can't be that much more secure. And the algorithm used in this particular exploit was able to trip -r3 but not -r1. Why is it possible for a unprivileged user to kill a root process. Unhelpful error messages like this aren't helpful either.
it didnt 'trip' -r1 because -r1 didnt do the detection ... and the race condition is small, but as you can see, doable, which is why the user didnt hit 100% of your emerge attempts in other words, it's quite possible that they were doing the samething but -r1 didnt care, it happily continued doing whatever it was doing ... we issued a GLSA about this but there are two real issues here ... (1) the fact that /tmp is used (but thats been filed elsewhere) (2) the error messages are pretty unhelpful
