Summary: | sys-apps/findutils-4.3.11 sandbox violation if PWD=/root on emerge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | New packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | haferfrost |
Priority: | High | Keywords: | InVCS, REGRESSION |
Version: | 2007.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 200044 | ||
Attachments: |
set HISTFILE=/dev/null to prevent sandbox violations
result of 'emerge -uvD world' after inserting 'set-x' add / to the default initial SANDBOX_READ |
Description
Juergen Rose
2007-12-18 14:15:30 UTC
i doubt it's a findutils issue what custom stuff do you have in /etc/portage/ Created attachment 138858 [details, diff]
set HISTFILE=/dev/null to prevent sandbox violations
I'm unable to reproduce the sandbox violation, but I think this patch might help you. Can you please test it?
If the patch is saved as /tmp/histfile.patch, then it can be applied as follows:
patch /usr/lib/portage/pym/portage.py < /tmp/histfile.patch
no need for the redirect ... this should work just as well: patch /usr/lib/portage/pym/portage.py /tmp/histfile.patch It has nothing to do with findutils. I think, that emerge tries to open .bash_history for reading in the current directory. If I calling emerge in the /root directory, emerge as user portage finds .bash_history of root and it is not allowed for portage to read the .bash_history of root. If I erase .bash_history of root I can also do emerge in the /root directory. The patch does not work for me. After applying I get: root@condor:/root(96)# emerge -vuD --newuse --skipfirst world * Overlay eclass overrides eclass from PORTDIR: * * '/usr/portage/local/layman/science/eclass/fortran.eclass' * * It is best to avoid overridding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to run `emerge --regen` after each time that you run `emerge * --sync`. Set PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you * would like to disable this warning. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] media-gfx/graphviz-2.16.1-r1 [2.16.1] USE="X examples gnome gtk jpeg nls perl png python tcl tk -doc -ruby (-cairo%*)" 0 kB [ebuild U ] app-office/gnucash-2.2.2 [2.2.1-r1] USE="-chipcard -debug -hbci -ofx -quotes" 6,916 kB [ebuild U ] net-voip/linphone-1.7.1-r1 [1.7.1] USE="alsa gtk%* ipv6 xv -arts% -console -ilbc -novideo" 0 kB [ebuild U ] x11-wm/icewm-1.2.33 [1.2.32] USE="esd nls spell truetype -debug -imlib -minimal (-uclibc) -xinerama" 811 kB Total: 4 packages (4 upgrades), Size of downloads: 7,726 kB *** Resuming merge... >>> Verifying ebuild Manifests... >>> Emerging (1 of 4) media-gfx/graphviz-2.16.1-r1 to / * graphviz-2.16.1.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking graphviz-2.16.1.tar.gz ;-) ... [ ok ] ACCESS DENIED open_rd: /dev/null ACCESS DENIED open_rd: /dev/null >>> Unpacking source... >>> Unpacking graphviz-2.16.1.tar.gz to /var/tmp/portage/media-gfx/graphviz-2.16.1-r1/work * Applying graphviz-2.16.1-bindings.patch ... [ ok ] * Applying graphviz-2.16.1-gcc43-missing-includes.patch ... [ ok ] * Applying graphviz-2.16.1-python-buildfix.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/media-gfx/graphviz-2.16.1-r1/work/graphviz-2.16.1' ... * Running aclocal ... [ ok ] * Running libtoolize --copy --force --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy ... [ ok ] * Running elibtoolize in: graphviz-2.16.1/lib/gd/config * Applying install-sh-1.5.patch ... * Applying ltmain-1.5.patch ... * Applying portage-1.5.10.patch ... * Applying relink-1.4.3.patch ... * Applying sed-1.5.6.patch ... * Applying tmp-1.3.5.patch ... * Running elibtoolize in: graphviz-2.16.1/config * Applying sed-1.5.6.patch ... >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-10224.log" open_rd: /dev/null open_rd: /dev/null A couple of odd things to note: 1) portage shouldn't be spawning interactive shells, so it doesn't make sense for bash to be accessing $HISTFILE 2) portage sets $HOME to a directory inside $PORTAGE_TMPDIR, so how do we explain $HOME/.bash_history taking a value of /root/.bash_history? Do you have anything in /etc/portage/bashrc? I don't have a /etc/portage/bashrc. root@vilm:/root(10)# ll -a /etc/portage/ total 56 drwxr-xr-x 7 root root 4096 Dec 19 10:03 ./ drwxr-xr-x 165 root root 8192 Dec 19 16:05 ../ -rw-r--r-- 1 root root 0 Dec 15 11:23 .keep_sys-apps_portage-0 drwxr-xr-x 2 root root 4096 Apr 9 2007 bin/ -rw-r--r-- 1 root root 10 Apr 30 2007 categories -rw-r--r-- 1 root root 65 Apr 17 2004 mirrors -rw-r--r-- 1 root root 1319 Nov 15 13:57 package.keywords -rw-r--r-- 1 root root 615 Nov 22 15:47 package.mask -rw-r--r-- 1 root root 323 Nov 7 00:46 package.unmask -rw-r--r-- 1 root root 3568 Dec 19 14:06 package.use drwxr-xr-x 2 root root 4096 Apr 9 2007 postsync.d/ drwxr-xr-x 2 root root 4096 Sep 26 2004 profile/ drwxr-xr-x 3 root root 4096 Jun 12 2007 savedconfig/ drwxrwsr-x 2 root portage 4096 Sep 23 2004 sets/ It similar happens if PWD ist /usr/src: root@shark:/usr/src(54)# emerge =vanilla-sources-2.6.23* * Overlay eclass overrides eclass from PORTDIR: * * '/usr/portage/local/layman/science/eclass/fortran.eclass' * * It is best to avoid overridding eclasses from PORTDIR because it will * trigger invalidation of cached ebuild metadata that is distributed with * the portage tree. If you must override eclasses from PORTDIR then you * are advised to run `emerge --regen` after each time that you run `emerge * --sync`. Set PORTAGE_ECLASS_WARNING_ENABLE="0" in /etc/make.conf if you * would like to disable this warning. Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) sys-kernel/vanilla-sources-2.6.23.12 to / * linux-2.6.23.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Downloading 'http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/distfiles/patch-2.6.23.12.bz2' --14:26:25-- http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/distfiles/patch-2.6.23.12.bz2 => `/usr/portage_shark/distfiles/patch-2.6.23.12.bz2' Resolving linux.rz.ruhr-uni-bochum.de... 134.147.32.114 Connecting to linux.rz.ruhr-uni-bochum.de|134.147.32.114|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 75,656 (74K) [application/x-bzip2] 100%[======================================================================================================>] 75,656 162.38K/s 14:26:26 (161.81 KB/s) - `/usr/portage_shark/distfiles/patch-2.6.23.12.bz2' saved [75656/75656] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking patch-2.6.23.12.bz2 ;-) ... [ ok ] * checking linux-2.6.23.tar.bz2 ;-) ... [ ok ] >>> Preparing to unpack ... ACCESS DENIED open_rd: /usr/src_shark/.bash_history ACCESS DENIED open_rd: /usr/src_shark/.bash_history >>> Unpacking source... >>> Unpacking linux-2.6.23.tar.bz2 to /var/tmp/portage/sys-kernel/vanilla-sources-2.6.23.12/work * Applying patch-2.6.23.12.patch (-p0+) ... [ ok ] >>> Source unpacked. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/var/log/sandbox/sandbox-26219.log" open_rd: /usr/src_shark/.bash_history open_rd: /usr/src_shark/.bash_history And it happens for for all (12) of my computes. What's in /etc/portage/profile/ ? On some computers this directory does not exist, on some computers it is a empty directory, on some computers it contains a package.provided file. But emerge complaines on all computers about an existing /root/.bash_history or /usr/src/.bash_history if it is called from /root or /usr/src directory Could it be that I have perhaps definded some macro in my environment, which emerge does not expect? Should I post the output of 'env', to compare my and yours environment? Regards Juergen Please edit /usr/lib/portage/bin/ebuild.sh and add 'set -x' on a line by itself just underneath the header. Then reproduce the problem and attach the output so we can see exactly where the access violation is occurring within the bash trace output. The 'environment' file (path shown at the bottom of the die message) might also be useful. Created attachment 139501 [details]
result of 'emerge -uvD world' after inserting 'set-x'
Created attachment 139502 [details, diff]
add / to the default initial SANDBOX_READ
Maybe this will help. If you save this patch as /tmp/sandbox_read.patch, then you can apply it as follows:
patch /usr/lib/portage/bin/ebuild.sh /tmp/sandbox_read.patch
I'm seeing this problem, too, with every package I try to emerge, regardless of PWD (so the summary description is too narrow). I tried previous portage versions and found that <=2.1.4_rc9 works and >=2.1.4_rc10 has the problem. So it seems to have been introduced between r9 and r10. (In reply to comment #14) Well, I can't reproduce the problem. Can you please test the patch from comment #13 and report back if it works? The fact that changes between rc9 and rc10 happen to trigger the problem doesn't really matter much. Lots of drastic changes had to be made and now we just have to do some minor adjustments to make sandbox happy. It's not like we can just revert something. It's a tunning issue. Yes, the patch makes the message go away. But I wouldn't call this a fix. I think portage has no business reading files inside of /root, so this access is IMHO a sandbox violation and should be reported as such. If I understand that patch correctly it will allow all reads anywhere in the file system to succeed without a sandbox violation message. I think that's a poor choice, even if it works as a short-term fix. I've examined the issue closer and found out that bash opens .bash_history for reading right after the command "declare -x HISTFILESIZE" is issued. This happens even in non-interactive shells (which one might consider a bash bug, since non-interactive shells don't use history). You can verify this easily by using strace on a shell script containing that command. The command "declare -x HISTFILESIZE" comes from the statement source "$T"/environment in ebuild.sh. So the root cause of the issue is the "declare -x HISTFILESIZE". ebuild.sh should probably filter it out in some way before sourcing the environment. That would get rid of the actual sandbox violation and not just suppress the reporting of it. As for the reason why this issue did not occur with portage versions <= rc9, this is because between rc9 and rc10, SANDBOX_ON was added to filtered_sandbox_vars in filter_readonly_variables() in ebuild.sh. If I remove that variable from the list, the issue disappears. So the actual access to root/.bash_history does occur even with rc9, but it is not reported. Regarding the question why you can't reproduce the issue, I can think of 2 things: 1) different bash version? (I have 3.2_p17-r1) 2) You don't have HISTFILE and/or HISTFILESIZE in your environment? I tested the patch on three computers. It worked for me. Juergen (In reply to comment #16) > Yes, the patch makes the message go away. But I wouldn't call this a fix. I > think portage has no business reading files inside of /root, so this access is > IMHO a sandbox violation and should be reported as such. If I understand that > patch correctly it will allow all reads anywhere in the file system to succeed > without a sandbox violation message. I think that's a poor choice, even if it > works as a short-term fix. Sandbox is only intended to be a quality assurance tool to protect against accidental write/replace/remove types of operations. It's not intended for protection against malicious attack. For protection against attack, we have this proposal: http://sources.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/ (In reply to comment #17) > I tested the patch on three computers. It worked for me. > Juergen Thanks, that patch is in svn. This has been released in 2.1.4_rc12. |