net-p2p/bitcoind (and probably net-p2p/bitcoin-qt) fails with a sandbox violation if git is installed and the path /.git exists. The problem is within bitcoin's genbuild.sh [1] script. The script *only* checks if the git command exists and if this is true, executes some git commands in ${S}. Since this is no git repository, git traverses it's way up, causing a sandbox violation if it finds and tries to open something under /.git At the time of reporting this bug, an pending bitcoin pull [2] request that fixes the genbuild.sh behavior exists (commit [3] to be precise). The fix for older ebuilds is trivial: Purge the git related code from genbuild.sh [1]: https://github.com/bitcoin/bitcoin/blob/a20c0d0f6792acf532309eee2e9f29120c801ee4/share/genbuild.sh#L14 [2]: https://github.com/bitcoin/bitcoin/pull/2805 [3]: https://github.com/theuni/bitcoin/commit/070ad14d4dcebe08769d58e0317abecc63d0630 Reproducible: Always Steps to Reproduce: 1. emerge git 2. cd / 3. sudo git init 4. emerge bitcoind
(In reply to Florian Schmaus from comment #0) > Reproducible: Always > > Steps to Reproduce: > 1. emerge git > 2. cd / > 3. sudo git init > 4. emerge bitcoind I just tried this and did not hit the sandbox violation. I emerge net-p2p/bitcoind-0.8.1. Can you give me your emerge --info, what USE flags are on with bitcoind, what version you're emerging and the output of the sanbox violations.
I am also unable to reproduce this right now. I tried with different states of a / git (i.e. with unstaged changes, with staged changes). And I don't have the log files any more. But I remember that the sandbox violation was regarding to '/.git' and that enabling epatch_user and putting the attached patch in /etc/portage/patches/net-p2p/bitcoind fixed the sandbox violation. The bug isn't really that serious, since it will only be triggered in some corner cases, where you need at last /.git and some yet unknown variable, and because the fix be likely in bitcoin(d|-qt)-0.8.3. I mostly reported it for completeness. I still wonder what's the unknown puzzle piece that is missing here.
Created attachment 353166 [details, diff] bitcoind-purge-git.patch
It's now fixed in the bitcoin source [1]. But the commit didn't made it into the 0.8.4 release. [1]: https://github.com/bitcoin/bitcoin/commit/35b8af92265ed74de63c3818e5290c27b3f35df2#L22R16
(In reply to Florian Schmaus from comment #4) > It's now fixed in the bitcoin source [1]. But the commit didn't made it into > the 0.8.4 release. > > > [1]: > https://github.com/bitcoin/bitcoin/commit/ > 35b8af92265ed74de63c3818e5290c27b3f35df2#L22R16 Still an issue?
Has been fixed upstream
Re-open, while the issue was initially fixed with https://github.com/bitcoin/bitcoin/commit/35b8af92265ed74de63c3818e5290c27b3f35df2#diff-951dcd404b79f141e39a1b071a4aa719R16 it got re-introduced into upstream via https://github.com/bitcoin/bitcoin/commit/c65cc8cde30dd34a81962fda51a754f1cc0bdde8 And the commit message of c65cc8cd appears that the easy fix to add "-a -d '.git'" to the condition won't be accepted by upstream. But maybe the gitanian builds would accept an env variable which indicates the gitdir.
Opened https://github.com/bitcoin/bitcoin/issues/5902 upstream; the commit you refer to implied it was just supposed to be temporary...
Is this still an issue with 0.12.1? It should still seek out .git, but only use it if it's related to the source code.
(In reply to Luke-Jr from comment #9) > Is this still an issue with 0.12.1? It should still seek out .git, but only > use it if it's related to the source code. I don't see this issue in net-p2p/bitcoind-0.13.0 (oldest) net-p2p/bitcoind-0.15.1 (newest) on an system prone to to the problem, i.e. no mountpoint between PORTAGE_TMPDIR and / (git stops at filesystem boundaries).
