If called, net-snmp tools create /usr/share/snmp/mibs/.index if it doesn't exist. If you care about the FHS, that's a problem (should be in /var, or not created at runtime). If you don't, it is still responsible for Gentoo bug reports about sandbox violations that are hard to reproduce (e.g. bug 17310, bug 195118, http://forum.soft32.com/linux/gentoo-php-ACCESS-DENIED-emerge-ftopict321749.html). In the case of bug 195118, a call to perl's find ("find(\&extract, $moduleDir);") triggers it. The ebuild for dev-php/PEAR-PEAR uses this work-around (ethereal used to have it, too): addpredict /usr/share/snmp/mibs/.index Debian had a longish discussion about the problem (originally started with permission problem) at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389434
This affects to a lot of packages, can anyone take a look on this? Thanks
RedHat discussion about this: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=523249
*** Bug 330965 has been marked as a duplicate of this bug. ***
This bug is also affecting user defined SNMP MIB directories. I have added mibdirs -/www/daten/mibs/Allgemein:/www/daten/mibs/HP-Compaq to /etc/snmp/snmp.conf. While emerging dev-php/PEAR-Spreadsheet_Excel_Writer-0.9.1-r1 I get following ACCESS VIOLATION: --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-436.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: open_wr S: deny P: /www/daten/mibs/Allgemein/.index A: /www/daten/mibs/Allgemein/.index R: /www/daten/mibs/Allgemein/.index C: php -d memory_limit=-1 -C -q -d include_path=/usr/share/php -d output_buffering=1 -d open_basedir= -d safe_mode=0 -d register_argc_argv=On -d auto_prepend_file= -d variables_order=EGPCS -d auto_append_file= /usr/share/php/pearcmd.php -d php_bin=/usr/bin/php -d www_dir=/usr/share/webapps/PEAR-Spreadsheet_Excel_Writer/0.9.1-r1/htdocs install --force --loose --nodeps --offline --packagingroot=/var/tmp/portage/dev-php/PEAR-Spreadsheet_Excel_Writer-0.9.1-r1/image/ /var/tmp/portage/dev-php/PEAR-Spreadsheet_Excel_Writer-0.9.1-r1/work/Spreadsheet_Excel_Writer-0.9.1/package.xml -------------------------------------------------------------------------------- Thus, adding addpredict seems not to be a valid workaround/solution. regards Daniel
We may discoverd a valid workaround/solution: Run following command on a machine which has userdefined mib dirs: snmpget -Dparse-mibs 2>&1 |egrep '^parse-mibs: Scanning directory ' |sed 's/^parse-mibs: Scanning directory //' You should now see your userdefined mib dirs next to the standard ones. If you set following environment variables and if you execute the above line you won't see your directories anymore: export MIBS=+ export MIBDIRS=+ May this is a starting point for a workaround?! regards Daniel
--- php-pear-r1.eclass.orig 2011-01-19 14:54:06.852584707 +0100 +++ php-pear-r1.eclass 2011-01-19 14:51:15.898205331 +0100 @@ -60,7 +60,7 @@ addpredict /var/lib/net-snmp/ addpredict /session_mm_cli0.sem - PHP_BIN="/usr/bin/php" + PHP_BIN="MIBDIRS=+ MIBS=+ /usr/bin/php" cd "${S}" Well at least this worked for PEAR. regards Daniel
*** Bug 360085 has been marked as a duplicate of this bug. ***
*** Bug 324319 has been marked as a duplicate of this bug. ***
*** Bug 250627 has been marked as a duplicate of this bug. ***
Created attachment 267197 [details, diff] Set --with-mibdirs= in src_configure() From the configure script: --with-mibdirs="dir1:dir2:" Default directories to look for mibs. (Default: \$HOME/.snmp/mibs:DATADIR/snmp/mibs) It looks like we could set that in econf to something plausible, like /tmp or anything else that portage allows one to write to. If that works, we would then perhaps have to set up a default runtime configuration to change that default to something usable. Could anyone apply this patch to an overlay, install net-snmp and then check whether its reverse dependencies start to behave properly?
Just came across this problem trying to install Chromium. For the record, the workaround in comment 5 worked for me. I just ran the snmpget command and didn't bother with the environment vars - after running snmpget the emerge command worked fine. The files in /usr/share/snmp/mibs/ were newer than the .index file, so I guess that's why it was trying to do an update. Maybe having them update elsewhere whenever MIBs change would also help?
*** Bug 371815 has been marked as a duplicate of this bug. ***
I just hit this issue again emerging libvpx-0.9.6. I tried to follow comment 5 and I found two directories: root@moose:/root(24)# snmpget -Dparse-mibs 2>&1 |egrep '^parse-mibs: Scanning directory ' |sed 's/^parse-mibs: Scanning directory //' /root/.snmp/mibs /usr/share/snmp/mibs But /root/.snmp/mibs does not exist. Is this normal? Btw., I found that snmp is not running: root@moose:/root(27)# /etc/init.d/snmpd status * status: stopped If I start /etc/init.d/snmpd, the issue disappears.
I have to correct myself. Starting /etc/init.d/snmpd helps only at two of four systems.
*** Bug 378433 has been marked as a duplicate of this bug. ***
I hit this issue again with media-libs/libvpx-0.9.7: Exporting MIBS=+ MIBDIRS=+ does not help: root@thinkpad:/root(9)# export MIBS=+ root@thinkpad:/root(10)# export MIBDIRS=+ root@thinkpad:/root(11)# emerge -v1 media-libs/libvpx These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-libs/libvpx-0.9.7 [0.9.6] USE="doc mmx sse sse2 threads (-altivec) -debug -postproc -sse3 -ssse3" 0 kB Total: 1 package (1 upgrade), Size of downloads: 0 kB >>> Verifying ebuild manifests >>> Emerging (1 of 1) media-libs/libvpx-0.9.7 * libvpx-v0.9.7.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking libvpx-v0.9.7.tar.bz2 to /var/tmp/portage/media-libs/libvpx-0.9.7/work >>> Source unpacked in /var/tmp/portage/media-libs/libvpx-0.9.7/work >>> Preparing source in /var/tmp/portage/media-libs/libvpx-0.9.7/work/libvpx-v0.9.7 ... * Applying libvpx-0.9.5-enable-shared.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-libs/libvpx-0.9.7/work/libvpx-v0.9.7 ... Configuring selected codecs enabling vp8_encoder enabling vp8_decoder Configuring for target 'x86-linux-gcc' enabling x86 enabling pic enabling runtime_cpu_detect enabling mmx enabling sse enabling sse2 enabling sse4_1 using yasm Creating makefiles for x86-linux-gcc libs Creating makefiles for x86-linux-gcc examples Creating makefiles for x86-linux-gcc docs >>> Source configured. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-21211.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: open_wr S: deny P: /usr/share/snmp/mibs/.index A: /usr/share/snmp/mibs/.index R: /usr/share/snmp/mibs/.index C: php -v -------------------------------------------------------------------------------- >>> Failed to emerge media-libs/libvpx-0.9.7, Log file: root@thinkpad:/root(12)# echo $MIPS root@thinkpad:/root(13)# echo $MIPSDIRS /etc/init.d/snmpd is not running, I can't start it easy, because snmpd complains about not running wlan0. But wlan0 is running, even if '/etc/init.d/net.wlan0 status' shows inactive: root@thinkpad:/root(14)# /etc/init.d/snmpd status * status: stopped root@thinkpad:/root(15)# /etc/init.d/snmpd start * WARNING: snmpd is scheduled to start when net.wlan0 has started root@thinkpad:/root(16)# /etc/init.d/net.wlan0 status * status: inactive root@thinkpad:/root(17)# ping ftp.cs.tu-berlin.de PING ftp.cs.tu-berlin.de (130.149.17.12) 56(84) bytes of data. 64 bytes from caramba.cs.tu-berlin.de (130.149.17.12): icmp_req=1 ttl=245 time=65.4 ms 64 bytes from caramba.cs.tu-berlin.de (130.149.17.12): icmp_req=2 ttl=245 time=66.2 ms 64 bytes from caramba.cs.tu-berlin.de (130.149.17.12): icmp_req=3 ttl=245 time=64.7 ms 64 bytes from caramba.cs.tu-berlin.de (130.149.17.12): icmp_req=4 ttl=245 time=65.4 ms 64 bytes from caramba.cs.tu-berlin.de (130.149.17.12): icmp_req=5 ttl=245 time=80.3 ms ^C --- ftp.cs.tu-berlin.de ping statistics --- 6 packets transmitted, 5 received, 16% packet loss, time 5006ms rtt min/avg/max/mdev = 64.747/68.443/80.372/5.982 ms Any hint is appreciated.
Hint: An unresolved bug is unresolved.
*** Bug 394593 has been marked as a duplicate of this bug. ***
*** Bug 432248 has been marked as a duplicate of this bug. ***
*** Bug 465988 has been marked as a duplicate of this bug. ***
I have added 5.7.2-r1 to the tree which sets econf [...] --with-mibdirs="." overriding the default /root/.snmp/mibs:/usr/share/snmp/mibs which is causing this sandbox violation. I am pretty sure this will break some systems.
(In reply to comment #21) > I have added 5.7.2-r1 to the tree which sets econf [...] --with-mibdirs="." > overriding the default /root/.snmp/mibs:/usr/share/snmp/mibs which is > causing this sandbox violation. I am pretty sure this will break some > systems. Oddly enough, on further testing, this didn't stop the sandbox violations at all since we still have --with-persistent-directory="/var/lib/net-snmp". I have removed the revision. :-(
For anyone adding addpredict to their ebuilds, perhaps a better way to deal with this is to do something like: addpredict $(net-snmp-config --persistent-directory --default-mibdirs)
*** Bug 537100 has been marked as a duplicate of this bug. ***
(In reply to Jeroen Roovers from comment #23) > For anyone adding addpredict to their ebuilds, perhaps a better way to deal > with this is to do something like: > > addpredict $(net-snmp-config --persistent-directory --default-mibdirs) Not sure if this is completely right.. --default-mibsdirs can include colon separated paths which addpredict fails to parse. This seems to work better: addpredict $(net-snmp-config --persistent-directory --default-mibdirs | sed 's/:/\n/') Please comment if there is an issue with this.
*** Bug 683908 has been marked as a duplicate of this bug. ***
*** Bug 594386 has been marked as a duplicate of this bug. ***
*** Bug 833434 has been marked as a duplicate of this bug. ***
(In reply to Brian Evans from comment #25) > (In reply to Jeroen Roovers from comment #23) > > For anyone adding addpredict to their ebuilds, perhaps a better way to deal > > with this is to do something like: > > > > addpredict $(net-snmp-config --persistent-directory --default-mibdirs) > > Not sure if this is completely right.. --default-mibsdirs can include colon > separated paths which addpredict fails to parse. > > This seems to work better: > > addpredict $(net-snmp-config --persistent-directory --default-mibdirs | sed > 's/:/\n/') > > > Please comment if there is an issue with this. netmon is a quiet project, go ahead
