Merging dev-php/theseer-Autoload-1.26.0-r2 fails with an access violation of the sandbox. It seems it tries to write to /var/lib/net-snmp/mib_indexes/0 ...? Reproducible: Always Steps to Reproduce: 1. emerge -1av dev-php/theseer-Autoload 2. 3. Actual Results: Sandbox Access Violation: * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- * LOG FILE: "/XXXXXX/portage/dev-php/theseer-Autoload-1.26.0-r2/temp/sandbox.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: fopen_wr S: deny P: /var/lib/net-snmp/mib_indexes/0 A: /var/lib/net-snmp/mib_indexes/0 R: /var/lib/net-snmp/mib_indexes/0 C: php ./phpab.php --output src/autoload.php --template /XXXXXX/portage/dev-php/theseer-Autoload-1.26.0-r2/files/autoload.php.tpl --basedir src src * -------------------------------------------------------------------------------- Expected Results: No access violation. What does theseer-Autoload have to do in /var/lib/net-snmp? Is this a hack attempt? Some info ========= Portage 3.0.28 (python 3.9.9-final-0, default/linux/amd64/17.1/hardened, gcc-11.2.0, glibc-2.33-r7, 5.4.168-gentoo x86_64) ================================================================= System uname: Linux-5.4.168-gentoo-x86_64-Intel-R-_Core-TM-_i7-6700HQ_CPU_@_2.60GHz-with-glibc2.33 Timestamp of repository gentoo: Sat, 22 Jan 2022 sh bash 5.1_p8 ld GNU ld (Gentoo 2.37_p1 p0) 2.37 app-misc/pax-utils: 1.3.3::gentoo app-shells/bash: 5.1_p8::gentoo dev-java/java-config: 2.3.1::gentoo dev-lang/perl: 5.34.0-r6::gentoo dev-lang/python: 2.7.18_p13::gentoo, 3.6.15::gentoo, 3.7.12_p1::gentoo, 3.8.12_p1-r1::gentoo, 3.9.9-r1::gentoo, 3.10.0_p1-r1::gentoo dev-lang/rust: 1.58.1::gentoo dev-lang/rust-bin: 1.53.0::gentoo dev-util/cmake: 3.21.4::gentoo dev-util/meson: 0.60.3::gentoo sys-apps/baselayout: 2.7-r3::gentoo sys-apps/openrc: 0.42.1::gentoo sys-apps/sandbox: 2.25::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo, 2.71-r1::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.12.6::gentoo, 1.13.4-r2::gentoo, 1.14.1::gentoo, 1.15.1-r2::gentoo, 1.16.4::gentoo sys-devel/binutils: 2.37_p1::gentoo sys-devel/binutils-config: 5.4::gentoo sys-devel/clang: 12.0.1::gentoo, 13.0.0::gentoo sys-devel/gcc: 7.5.0::gentoo, 8.3.0-r1::gentoo, 8.4.0::gentoo, 9.3.0::gentoo, 11.2.0::gentoo sys-devel/gcc-config: 2.5-r1::gentoo sys-devel/libtool: 2.4.6-r6::gentoo sys-devel/lld: 13.0.0::gentoo sys-devel/llvm: 12.0.1::gentoo, 13.0.0::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.15-r3::gentoo (virtual/os-headers) sys-libs/glibc: 2.33-r7::gentoo
Created attachment 765211 [details] build.log
*** This bug has been marked as a duplicate of bug 249496 ***
So this bug was "resolved" as duplicate of an unresolved bug. Hmm... I tried to research this a bit, but I am not sure what to think of it: It seems that other PHP scripts trigger it - composer triggered it 8 years ago: https://stackoverflow.com/questions/18841041/composer-installed-net-snmp Here it is triggered by the "phpab.php" script: ...portage/dev-php/theseer-Autoload-1.26.0-r2/work/Autoload-1.26.0/phpab.php Looking there, there are just two lines $factory = new \TheSeer\Autoload\Factory(); $factory->getCLI()->run(); I would suspect the PHP CLI, but I have ; The MIBS data available in the PHP distribution must be installed. ; See http://www.php.net/manual/en/snmp.installation.php ;extension=snmp in the php.ini of the CLI, i.e. SNMP is disabled for PHP. On the other side php-config shows --with-snmp=/usr ...and php has the 'snmp' USE flag set. But the daemon is not running: /etc/init.d/snmpd status * status: stopped Clearly, either PHP CLI, or theseer-Autoload try to access SNMP functionality, even in the case this is clearly disabled/not available/not running. This is unfortunate, but probably hard to fix in a distribution. So what would you suggest as a workaround: - Disable the 'snmp' USE flag for all PHP slots, remerge them and retry? - Disable the 'snmp' USE flag globally - this will cause rebuilds for: dev-lang/php-XX app-admin/syslog-ng media-gfx/sane-backends net-analyzer/nagios-plugins net-analyzer/openvas-scanner and then depclean net-snmp alltogether: emerge -av --depclean net-analyzer/net-snmp and retry? - Add /var/lib/net-snmp/mib_indexes to the SANDBOX_WRITE variable in, say /etc/sandbox.d/00default thus allowing the write operation to /var/lib/net-snmp/mib_indexes/0 - at least for the time of merging (one can take it back afterwards)? If this is harmless from a security point of view (as it seems to be), then personally I tend to the latter solution. What is your opinion?
