[gentoo-dev] [PATCH 1/2] media-fonts/x11fonts-jmk: Install files with 0644 permissions

[gentoo-dev] [PATCH 1/2] media-fonts/x11fonts-jmk: Install files with 0644 permissions

[Matt Turner]

font.eclass has some racy code in pkg_postinst() that changes
permissions of already-installed files. I want to remove that to avoid
the race. This is the only package that installs fonts with permissions
other than 0644, so override that in src_install().

The claim in font.eclass is that fontconfig segfaults if fonts are
unreadable, but that claim dates to 2007 (bug #187774). Additionally,
0444 is readable, but who knows. Let's just keep things working how they
have been since 2007.

Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner <mattst88@gentoo.org>
---
 media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
index 70ad93064b5..f24d067c412 100644
--- a/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
+++ b/media-fonts/x11fonts-jmk/x11fonts-jmk-3.0-r4.ebuild
@@ -32,6 +32,6 @@ src_configure() {
 }
 
 src_install() {
-	emake install INSTALL_DIR="${ED}/usr/share/fonts/jmk"
+	emake install INSTDATFLAGS="-m 0644" INSTALL_DIR="${ED}/usr/share/fonts/jmk"
 	einstalldocs
 }
-- 
2.37.4

[gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

[Matt Turner]

Noticed on ChromeOS when installing a large number of font packages in
parallel:

/usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (------r--) to 2440 (r--r-S---)
* ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
*   failed to fix font files perms

The "#new" filename is the hint. Portage uses "#new" suffixes when
copying files to the system, and then renames them to their final
filenames.

This code was executing while another font was in the process of being
copied to the system. Font packages should just ensure that they install
files with correct permissions to begin with, and all except
media-fonts/x11fonts-jmk already use 0644 permissions.
media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
previous commit which changes its installed files to 0644.

Bug: https://bugs.gentoo.org/187774
Signed-off-by: Matt Turner <mattst88@gentoo.org>
---
 eclass/font.eclass | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/eclass/font.eclass b/eclass/font.eclass
index 4970c959f7c..0196755ce3e 100644
--- a/eclass/font.eclass
+++ b/eclass/font.eclass
@@ -186,12 +186,6 @@ font_src_install() {
 # @DESCRIPTION:
 # Updates fontcache if !prefix and media-libs/fontconfig installed
 _update_fontcache() {
-	if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
-		# unreadable font files = fontconfig segfaults
-		find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
-			-exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files perms"
-	fi
-
 	if [[ -z ${ROOT} ]] ; then
 		if has_version media-libs/fontconfig ; then
 			ebegin "Updating global fontcache"
-- 
2.37.4

Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]



> On 8 Nov 2022, at 01:10, Matt Turner <mattst88@gentoo.org> wrote:
> 
> Noticed on ChromeOS when installing a large number of font packages in
> parallel:
> 
> /usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (------r--) to 2440 (r--r-S---)
> * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
> *   failed to fix font files perms
> 
> The "#new" filename is the hint. Portage uses "#new" suffixes when
> copying files to the system, and then renames them to their final
> filenames.
> 
> This code was executing while another font was in the process of being
> copied to the system. Font packages should just ensure that they install
> files with correct permissions to begin with, and all except
> media-fonts/x11fonts-jmk already use 0644 permissions.
> media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
> previous commit which changes its installed files to 0644.
> 
> Bug: https://bugs.gentoo.org/187774
> Signed-off-by: Matt Turner <mattst88@gentoo.org>
> ---
> eclass/font.eclass | 6 ------
> 1 file changed, 6 deletions(-)
> 
> diff --git a/eclass/font.eclass b/eclass/font.eclass
> index 4970c959f7c..0196755ce3e 100644
> --- a/eclass/font.eclass
> +++ b/eclass/font.eclass
> @@ -186,12 +186,6 @@ font_src_install() {
> # @DESCRIPTION:
> # Updates fontcache if !prefix and media-libs/fontconfig installed
> _update_fontcache() {
> - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
> - # unreadable font files = fontconfig segfaults
> - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
> - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files perms"
> - fi
> -
> if [[ -z ${ROOT} ]] ; then
> if has_version media-libs/fontconfig ; then
> ebegin "Updating global fontcache"
> --

Can we put an fperms call in src_install just in case (like the eclass originally had
before moved to pkg_postinst)?


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 358 bytes --]

Re: [gentoo-dev] [PATCH 2/2] font.eclass: Remove racy pkg_postinst code

[Matt Turner]

On Mon, Nov 7, 2022 at 11:11 PM Sam James <sam@gentoo.org> wrote:
>
>
>
> > On 8 Nov 2022, at 01:10, Matt Turner <mattst88@gentoo.org> wrote:
> >
> > Noticed on ChromeOS when installing a large number of font packages in
> > parallel:
> >
> > /usr/share/fonts/noto/NotoSerifThai-Regular.ttf#new' from 0004 (------r--) to 2440 (r--r-S---)
> > * ERROR: media-fonts/ipaex-004.01-r1::chromiumos failed (postinst phase):
> > *   failed to fix font files perms
> >
> > The "#new" filename is the hint. Portage uses "#new" suffixes when
> > copying files to the system, and then renames them to their final
> > filenames.
> >
> > This code was executing while another font was in the process of being
> > copied to the system. Font packages should just ensure that they install
> > files with correct permissions to begin with, and all except
> > media-fonts/x11fonts-jmk already use 0644 permissions.
> > media-fonts/x11fonts-jmk used 0444 (which was probably fine) until the
> > previous commit which changes its installed files to 0644.
> >
> > Bug: https://bugs.gentoo.org/187774
> > Signed-off-by: Matt Turner <mattst88@gentoo.org>
> > ---
> > eclass/font.eclass | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/eclass/font.eclass b/eclass/font.eclass
> > index 4970c959f7c..0196755ce3e 100644
> > --- a/eclass/font.eclass
> > +++ b/eclass/font.eclass
> > @@ -186,12 +186,6 @@ font_src_install() {
> > # @DESCRIPTION:
> > # Updates fontcache if !prefix and media-libs/fontconfig installed
> > _update_fontcache() {
> > - if [[ -d "${EROOT}"/usr/share/fonts ]] ; then
> > - # unreadable font files = fontconfig segfaults
> > - find "${EROOT}"/usr/share/fonts/ -type f '!' -perm 0644 \
> > - -exec chmod -v 0644 2>/dev/null {} + || die "failed to fix font files perms"
> > - fi
> > -
> > if [[ -z ${ROOT} ]] ; then
> > if has_version media-libs/fontconfig ; then
> > ebegin "Updating global fontcache"
> > --
>
> Can we put an fperms call in src_install just in case (like the eclass originally had
> before moved to pkg_postinst)?

We can if you think it's necessary, but to be honest I think that the
original bug should have been WONTFIX. The user was manually
installing fonts into their system and then complained that things
didn't work when they configured the fonts with the wrong permissions.

I don't think fonts getting installed with unreadable permissions is a
real problem.