I'm trying to install a live ebuild, namely net-misc/youtube-dl-99999999. However, it fails to download the sources from github.com while I can download them manually just fine. Reproducible: Always Steps to Reproduce: 1. ACCEPT_KEYWORDS='**' emerge -v1 youtube-dl Actual Results: >>> Unpacking source... * Repository id: rg3_youtube-dl.git * To override fetched repository properties, use: * EGIT_OVERRIDE_REPO_RG3_YOUTUBE_DL * EGIT_OVERRIDE_BRANCH_RG3_YOUTUBE_DL * EGIT_OVERRIDE_COMMIT_RG3_YOUTUBE_DL * EGIT_OVERRIDE_COMMIT_DATE_RG3_YOUTUBE_DL * * Fetching https://github.com/rg3/youtube-dl ... git fetch https://github.com/rg3/youtube-dl +HEAD:refs/git-r3/HEAD fatal: unable to access 'https://github.com/rg3/youtube-dl/': Could not resolve host: github.com * ERROR: net-misc/youtube-dl-99999999::gentoo failed (unpack phase): * Unable to fetch from any of EGIT_REPO_URI * * Call stack: * ebuild.sh, line 125: Called src_unpack * environment, line 3438: Called git-r3_src_unpack * environment, line 2159: Called git-r3_src_fetch * environment, line 2153: Called git-r3_fetch * environment, line 2075: Called die * The specific snippet of code: * [[ -n ${success} ]] || die "Unable to fetch from any of EGIT_REPO_URI"; Expected Results: `git fetch` is successful. I tried with both (stable) sys-apps/portage-2.3.69 and (unstable) sys-apps/portage-2.3.70 -- the result is the same. github.com is perfectly resolvable: $ nslookup github.com Server: 10.0.0.1 Address: 10.0.0.1#53 Non-authoritative answer: Name: github.com Address: 140.82.113.3 Strace of the whole emerge process shows (10.0.0.1 is the DNS): [pid 21619] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 [pid 21619] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable ) [pid 21619] close(3) = 0 [pid 21619] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 [pid 21619] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable ) [pid 21619] close(3) = 0 [pid 21619] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 [pid 21619] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable ) [pid 21619] close(3) = 0 [pid 21619] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3 [pid 21619] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.0.1")}, 16) = -1 ENETUNREACH (Network is unreachable ) I hacked git command and here's the result of `ip addr` output from it: """ Arguments: fetch https://github.com/rg3/youtube-dl +HEAD:refs/git-r3/HEAD Running ip addr: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever """ So, clearly, src_unpack() stage of the live ebuild (it does have PROPERTIES=live) is run in a non-networked sandbox, which doesn't seem right.
Created attachment 585738 [details] emerge --info
Hm, the network namespace is shared with the initial namespace at least until the execution of sandbox: """ qqq: command: ['/usr/bin/python3.6m', '/usr/lib/portage/python3.6/pid-ns-init', b'250', b'250', b'250', b'18', b'0,1,2', '/usr/bin/sandbox', b'[net-misc/youtube-dl-99999999] sandbox', b'/usr/lib/portage/python3.6/ebuild.sh unpack'] has eth0: True >>> Unpacking source... ... git fetch https://github.com/rg3/youtube-dl +HEAD:refs/git-r3/HEAD fatal: unable to access 'https://github.com/rg3/youtube-dl/': Could not resolve host: github.com """ The output is produced with the following hack: --- /usr/lib64/python3.6/site-packages/portage/process.py 2019-08-05 05:13:43.367664411 +0300 +++ /usr/lib64/python3.6/site-packages/portage/process.py 2019-08-05 05:11:56.465521930 +0300 @@ -681,6 +682,7 @@ def _exec(binary, mycommand, opt_name, f if pre_exec: pre_exec() + print(f"qqq: command: {str(myargs)} has eth0: {'eth0' in subprocess.check_output(['/bin/ip', 'a']).decode()}") # And switch to the new process. os.execve(binary, myargs, env) If I comment out NAMESPACE_NET_ENABLE="yes" in /etc/sandbox.conf, then `git fetch` starts to work fine.
You really should not set NAMESPACE_NET_ENABLE="yes" in sandbox.conf. Let portage manage the namespace via FEATURES="network-sandbox" instead.
Huh, sorry! I was wondering why there are no existing bug reports on the matter... I must have changed it long time ago and completely forgot about it. If I restore sandbox.conf to the default one (so that `equery check sandbox` passes), then `git fetch` works just fine. This is what I had changed compared to the default sandbox.conf: --- /etc/sandbox.conf.default 2019-08-05 06:30:50.357654557 +0300 +++ /etc/sandbox.conf.bad 2019-08-05 05:19:03.430079966 +0300 @@ -33,19 +33,19 @@ # # Global knob to control all namespaces. -#NAMESPACES_ENABLE="no" +NAMESPACES_ENABLE="yes" # Knobs for different types of namespaces. If the runtime doesn't support a # particular type, it will be automatically skipped. Default to off as these # are currently experimental. # For more details on each type, see the namespaces(7) manpage. -#NAMESPACE_IPC_ENABLE="no" -#NAMESPACE_MNT_ENABLE="no" -#NAMESPACE_NET_ENABLE="no" -#NAMESPACE_PID_ENABLE="no" -#NAMESPACE_SYSV_ENABLE="no" -#NAMESPACE_USER_ENABLE="no" -#NAMESPACE_UTS_ENABLE="no" +NAMESPACE_IPC_ENABLE="yes" +NAMESPACE_MNT_ENABLE="yes" +NAMESPACE_NET_ENABLE="yes" +NAMESPACE_PID_ENABLE="yes" +NAMESPACE_SYSV_ENABLE="yes" +NAMESPACE_USER_ENABLE="yes" +NAMESPACE_UTS_ENABLE="yes" NAMESPACE_* knobs are marked as experimental, but the comments don't say that normally portage controls the use of namespaces in its sandbox. So, it would be nice if the comments are made clearer, that portage takes care of everything on its own.
I think users might want to use sandbox for their own purposes too (not that this is a common use case), so it'd be nice if the system configuration didn't affect portage like this? Though on other aspects it's good that it does.. maybe portage should override these specific settings to their default to ensure it doesn't break when a user has changed them in the global configuration for their own reasons?
Would it suffice for portage to call sandbox with the --ns-off option? I see this option has existed since bug 512794.
(In reply to Zac Medico from comment #6) portage can just require a recent version of sandbox and them assume options via that. in this case, it seems like using --ns-net-off when PROPERTIES=live and running the src_unpack phase is the way to go.
Portage implements several namespace-based sandbox features itself. Setting up yet another layer of namespaces via sys-apps/sandbox is a bit redundant. I would just pass "--ns-off" to disable them all, or at least disable the ones that overlap with those already provided by Portage.
