Bug 662240 – www-client/firefox-61.0-r1 failing at configure: Permission denied: '/etc'

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Massimo Burcheri 2018-07-27 09:48:00 UTC]

www-client/firefox-61.0-r1 fails with Permission denied :'/etc' while firefox-60.1.0 works fine.

Reproducible by
# ebuild `equery w firefox-61.0-r1` clean configure

The build is done on a dedicated btrfs subvolume, but also fails on a 13GB tmpfs.

Investigating the sources it tries to read the gentoo-release which is readable:

# ls -ald / /etc /etc/gentoo-release 
drwxr-xr-x 1 root root  368 Jun 27 12:13 /
drwxr-x--x 1 root root 5248 Jul 27 10:52 /etc
-rw-rw-r-- 1 root root   31 Jul 26 08:18 /etc/gentoo-release

ccache is active here, but it fails also with FEATURES="-ccache"

[Comment 1 Massimo Burcheri 2018-07-27 10:02:05 UTC]

Created attachment 541198 [details]
emerge --info

[Comment 2 Massimo Burcheri 2018-07-27 10:03:39 UTC]

Created attachment 541200 [details]
emerge -pvq firefox::gentoo

[Comment 3 Massimo Burcheri 2018-07-27 10:55:16 UTC]

Created attachment 541202 [details]
/var/log/portage/www-client:firefox-61.0-r1:20180724-084437.log.gz

[Comment 4 Alexander Tsoy 2018-08-02 06:28:08 UTC]

(In reply to Massimo Burcheri from comment #0)
> Investigating the sources it tries to read the gentoo-release which is
> readable:
> 
> # ls -ald / /etc /etc/gentoo-release 
> drwxr-xr-x 1 root root  368 Jun 27 12:13 /
> drwxr-x--x 1 root root 5248 Jul 27 10:52 /etc

/etc is not readable by non-root users, that's why the following code in distro.py fails:

basenames = os.listdir(_UNIXCONFDIR)

[Comment 5 Massimo Burcheri 2018-08-02 06:48:28 UTC]

What is the correct permission for /etc?
Why does the older Firefox ebuild work?

[Comment 6 Massimo Burcheri 2018-08-02 07:16:22 UTC]

I see, my drwxr-x--x on /etc is breaking the listdir.
This is the first ebuild since years failing with that. In my eyes drwxr-x--x is the better permission for /etc.
Firefox doesn't need to do the listdir, it could also just check for any file it expects there. Could the ebuild patch that in any way? The behaviour seems to be new in 61.0-r1.

[Comment 7 Alexander Tsoy 2018-08-02 07:34:48 UTC]

BTW, this is fixed in newer pip:
https://github.com/pypa/pip/commit/270ea3af207273b4815d73b10e83b580387adeaf

The problem is that the pip is shipped as .whl package in the firefox tarball, so it would be hard to patch.

[Comment 8 Massimo Burcheri 2018-08-02 07:53:28 UTC]

Thanks. So I revert the permission to my previous setting and wait for the next ebuild including the newer pip. Please keep this open until solved by the next ebuild.

[Comment 9 Thomas Deutschmann (RETIRED) 2018-09-27 20:54:16 UTC]

I requested a bump of bundled PIP upstream, https://bugzilla.mozilla.org/show_bug.cgi?id=1494779

[Comment 10 Thomas Deutschmann (RETIRED) 2020-10-04 18:02:20 UTC]

Fixed in firefox-72+