search

archmac / packages

PKGBUILD and assorted files for building packages
https://www.archmac.org
14 stars 1 forks source link

Newer binary package files have wrong (non-root) owner / broken fakeroot? #8

Open nanoant opened 4 years ago

nanoant commented 4 years ago

Sorry it is me again 🙄

It seems that new packages built this year contain user 501 (aka 1st macOS user or distiller) files owner. While older 2018 have 0 (root) as I would expect. See below. This causes all files to be installed with non-root permissions, which causes complete mess in /opt/arch permissions.

Also I think fakeroot is not really working, at least not at my 10.14.6. All packages I build with makepkg get my UID 501 as an owner for package files. At least I don't see that files are being created as root, it looks like fakeroot does absolutely nothing on my machine.

I tried to look for the answers if Debian's fakeroot(with correct patches) is supposed to work at all on newer macOS (e.g. due to all the recent security changes), but I found absolutely no information.

Do you have any clues?

$ bsdtar --list -vf /opt/arch/var/cache/pacman/pkg/bash-4.4.019-3-x86_64.pkg.tar.gz | head -8
-rw-r--r--  0 root   wheel     379 Apr 18  2018 .PKGINFO
-rw-r--r--  0 root   wheel    1144 Apr 18  2018 .BUILDINFO
-rw-r--r--  0 root   wheel     405 Apr 18  2018 .INSTALL
-rw-r--r--  0 root   wheel   10952 Apr 18  2018 .MTREE
drwxr-xr-x  0 root   wheel       0 Apr 18  2018 opt/
drwxr-xr-x  0 root   wheel       0 Apr 18  2018 opt/arch/
drwxr-xr-x  0 root   wheel       0 Apr 18  2018 opt/arch/bin/
drwxr-xr-x  0 root   wheel       0 Apr 18  2018 opt/arch/include/

$ bsdtar --list --numeric-owner -vf /opt/arch/var/cache/pacman/pkg/bash-4.4.019-3-x86_64.pkg.tar.gz | head -8
-rw-r--r--  0 0      0         379 Apr 18  2018 .PKGINFO
-rw-r--r--  0 0      0        1144 Apr 18  2018 .BUILDINFO
-rw-r--r--  0 0      0         405 Apr 18  2018 .INSTALL
-rw-r--r--  0 0      0       10952 Apr 18  2018 .MTREE
drwxr-xr-x  0 0      0           0 Apr 18  2018 opt/
drwxr-xr-x  0 0      0           0 Apr 18  2018 opt/arch/
drwxr-xr-x  0 0      0           0 Apr 18  2018 opt/arch/bin/
drwxr-xr-x  0 0      0           0 Apr 18  2018 opt/arch/include/

$ bsdtar --list -vf /opt/arch/var/cache/pacman/pkg/pacman-5.0.2-4-x86_64.pkg.tar.gz | head -8
-rw-r--r--  0 distiller staff     647 Jul 31 17:54 .PKGINFO
-rw-r--r--  0 distiller staff    1198 Jul 31 17:54 .BUILDINFO
-rw-r--r--  0 distiller staff   17194 Jul 31 17:54 .MTREE
drwxr-xr-x  0 distiller staff       0 Jul 31 17:54 opt/
drwxr-xr-x  0 distiller staff       0 Jul 31 17:54 opt/arch/
drwxr-xr-x  0 distiller staff       0 Jul 31 17:54 opt/arch/bin/
drwxr-xr-x  0 distiller staff       0 Jul 31 17:54 opt/arch/etc/
drwxr-xr-x  0 distiller staff       0 Jul 31 17:54 opt/arch/include/

$ bsdtar --list --numeric-owner -vf /opt/arch/var/cache/pacman/pkg/pacman-5.0.2-4-x86_64.pkg.tar.gz | head -8
-rw-r--r--  0 501    20        647 Jul 31 17:54 .PKGINFO
-rw-r--r--  0 501    20       1198 Jul 31 17:54 .BUILDINFO
-rw-r--r--  0 501    20      17194 Jul 31 17:54 .MTREE
drwxr-xr-x  0 501    20          0 Jul 31 17:54 opt/
drwxr-xr-x  0 501    20          0 Jul 31 17:54 opt/arch/
drwxr-xr-x  0 501    20          0 Jul 31 17:54 opt/arch/bin/
drwxr-xr-x  0 501    20          0 Jul 31 17:54 opt/arch/etc/
drwxr-xr-x  0 501    20          0 Jul 31 17:54 opt/arch/include/
lloeki commented 4 years ago

Yeah this is strange. I noticed it but only on a couple of files if I recall correctly (e.g some zsh autocompletion files), seems like it's worse than I originally though. I have no real information, sadly it's a pain to get any regarding how fakeroot works at all...

nanoant commented 4 years ago

Okay, I suspect this may be due to Apple's macOS built-in /usr/bin/bsdtar being for some reason used for some recent packages instead of /opt/arch/bin/bsdtar.

AFAIK all built-in binaries signed by Apple use hardened runtime that ignores DYLD_INSERT_LIBRARIES injection required by fakeroot, but otherwise they will not complain or fail - it will just make whole fakeroot thing non-operational for them. Btw. fakeroot still seems to be working for non-hardneded apps.

I think putting /opt/arch/bin and/or making sure /opt/arch/bin/bsdtar is selected for package solves the problem. At least I can reproduce the problem if /opt/arch/bin is not in the front in the PATH, then I get also wrong owner/group in the produced packages, but if it is in the front then I get proper root owned files, e.g.:

~/Code/ArchMac/packages/core/pacman
$ bsdtar --list --numeric-owner -vf pacman-5.1.2-1-x86_64.pkg.tar.gz | head -8
-rw-r--r--  0 0      0        1472 Nov 22 22:03 .BUILDINFO
-rw-r--r--  0 0      0       19432 Nov 22 22:03 .MTREE
-rw-r--r--  0 0      0         648 Nov 22 22:03 .PKGINFO
drwxr-xr-x  0 0      0           0 Nov 22 22:03 opt/
drwxr-xr-x  0 0      0           0 Nov 22 22:03 opt/arch/
drwxr-xr-x  0 0      0           0 Nov 22 22:03 opt/arch/bin/
-rwxr-xr-x  0 0      0        9620 Nov 22 22:03 opt/arch/bin/cleanupdelta
-rwxr-xr-x  0 0      0       47992 Nov 22 22:03 opt/arch/bin/makepkg

Nevertheless it is pretty weird since I see packages/.circleci/config.yml have the Arch binaries first in the PATH. So I am not sure how this has happened. Also it is a bit disappointing that we need that fakeroot to build packages at all, and this is mostly to make sure that files get owned by root. --uid and --gid bsdtar flags could be used instead.

Now the question is.. what should be done with these packages with broken permissions?

Btw. I managed to add some extra packages there in my fork https://github.com/nanoant/archmac-packages/commits/master, but one (glib2) has still broken permissions, despite proper PATH. I suspect that install script somehow escapes macOS fakeroot there. 😠 Other packages have good permissions.

lloeki commented 4 years ago

Looks like something I remember! Signed binaries are ignoring DYLD_INSERT_LIBRARIES, forgot about that! We should use our own bsdtar and install tool indeed.

Now the question is.. what should be done with these packages with broken permissions?

Fix the cause and have them rebuilt by bumping pkgrel. It's never good to replace an already published package version.

nanoant commented 4 years ago

I think Arch Mac owns already bsdtar but indeed not install (on Arch Linux it is part of coreutils), maybe we should port coreutils partially.

$ pacman -Qo `which bsdtar`
/opt/arch/bin/bsdtar is owned by libarchive 3.3.1-1

It would be great to have install that accepts -D and -t, because porting install -Dm644 into two lines is annoying, and this is almost in every package. I occasionally monitor built packages with:

find . -name '*.pkg.*' \
    -exec bsdtar --list -vf {} \; | \
    grep ' myusername'

And /opt/arch prefix with:

find /opt/arch ! -user root
lloeki commented 4 years ago

I'm looking into this. Successfully built coreutils with a g prefix for conflicting ones, and seems like: