[GH-ISSUE #1800] Gentoo portage "emerge" cant find what it just downloaded with wget #1222

Closed
opened 2026-05-05 07:40:56 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @ThePythonicCow on GitHub (Mar 6, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1800

The Gentoo portage command to install/update software "emerge --ask somepackage" fails for me. It seems to download the appropriate version of "somepackage" from the appropriate Gentoo server, but then fails immediately when it can't find what it just downloaded.

I have only recently converted to Gentoo, and I have just started running firejail in this setup, so I don't have a prior history of this working.

My Gentoo version: Gentoo Base System release 2.4.1
The "emerge --version": Portage 2.3.19 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, gcc-6.4.0, glibc-2.25-r10, 4.15.2 x86_64)
The "firejail --version": firejail version 0.9.50

I diagnosed the problem by using strace on the session within which I ran the failing emerge invocations. I could see the emerge command invoke /usr/local/bin/wget to download of the desired package. This wget download would run to successful completion, but then immediately thereafter, the invoking emerge code would fail, complaining that it could not see what it just had wget download.

If I remove /usr/local/bin/wget (the symlink to /usr/bin/firejail), then emerge uses /usr/bin/wget, the non-firejailed instance of wget, and emerge successfully installs and upgrades all packages that I have tried, and otherwise behaves as expected.

Originally created by @ThePythonicCow on GitHub (Mar 6, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1800 The Gentoo portage command to install/update software "emerge --ask somepackage" fails for me. It seems to download the appropriate version of "somepackage" from the appropriate Gentoo server, but then fails immediately when it can't find what it just downloaded. I have only recently converted to Gentoo, and I have just started running firejail in this setup, so I don't have a prior history of this working. **My Gentoo version**: Gentoo Base System release 2.4.1 **The "emerge --version"**: Portage 2.3.19 (python 3.5.4-final-0, default/linux/amd64/17.0/desktop, gcc-6.4.0, glibc-2.25-r10, 4.15.2 x86_64) **The "firejail --version"**: firejail version 0.9.50 I diagnosed the problem by using strace on the session within which I ran the failing emerge invocations. I could see the emerge command invoke /usr/local/bin/wget to download of the desired package. This wget download would run to successful completion, but then immediately thereafter, the invoking emerge code would fail, complaining that it could not see what it just had wget download. If I remove /usr/local/bin/wget (the symlink to /usr/bin/firejail), then emerge uses /usr/bin/wget, the non-firejailed instance of wget, and emerge successfully installs and upgrades all packages that I have tried, and otherwise behaves as expected.
gitea-mirror 2026-05-05 07:40:56 -06:00
Author
Owner

@Ferroin commented on GitHub (Mar 6, 2018):

So, this is just me, but this sounds like a classic 'it hurts if I do X' problem.

Emerge should already be sandboxing downloads to a certain degree (make sure you have the userfetch feature enabled in make.conf), and sandboxing beyond that is of questionable value because you already functionally have to trust the systems you're downloading the source archives for the packages from, otherwise you can't trust those packages once built (and you can't just run everything in firejail, there's core system components at stake here that if compromised make any kind of sandboxing mostly irrelevant (think stuff like openssl or the Python interpreter)).

<!-- gh-comment-id:370771935 --> @Ferroin commented on GitHub (Mar 6, 2018): So, this is just me, but this sounds like a classic 'it hurts if I do X' problem. Emerge should already be sandboxing downloads to a certain degree (make sure you have the `userfetch` feature enabled in make.conf), and sandboxing beyond that is of questionable value because you already functionally have to trust the systems you're downloading the source archives for the packages from, otherwise you can't trust those packages once built (and you can't just run everything in firejail, there's core system components at stake here that if compromised make any kind of sandboxing mostly irrelevant (think stuff like openssl or the Python interpreter)).
Author
Owner

@Vincent43 commented on GitHub (Mar 6, 2018):

I guess this and https://github.com/netblue30/firejail/issues/1801 are working as intended. I think the problem is that certain tools used for system administration shouldn't be included in default firecfg config. I'll make a PR which remove them.

<!-- gh-comment-id:370816004 --> @Vincent43 commented on GitHub (Mar 6, 2018): I guess this and https://github.com/netblue30/firejail/issues/1801 are working as intended. I think the problem is that certain tools used for system administration shouldn't be included in default firecfg config. I'll make a PR which remove them.
Author
Owner

@netblue30 commented on GitHub (Mar 6, 2018):

Let's close #1800 and #1801and move the discussion to https://github.com/netblue30/firejail/pull/1802 until we find a fix.

<!-- gh-comment-id:370828933 --> @netblue30 commented on GitHub (Mar 6, 2018): Let's close #1800 and #1801and move the discussion to https://github.com/netblue30/firejail/pull/1802 until we find a fix.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1222
No description provided.