Block builds from creating/deleting users/groups

[waddlesplash]

Realistically, this should be done on the Haiku side; right now anything which is UID 0 (even if it's in a chroot) can do this. But for the moment, we can prevent this from happening by creating a package settings file blocklisting useradd, groupadd, etc. in chroot setup (

haikuporter/HaikuPorter/ShellScriptlets.py

Line 862 in 007d868

# activate system inputrc in chroot, for improved navigation

).

This problem was the cause of the new Git recipe (haikuports/haikuports#9569) failing to build:

1. In 2019, some build (@mmlr believes it to be https://build.haiku-os.org/buildmaster/master/x86_64/?buildrunDir=2953&viewMode=expanded) created a user named root. As the root user on Haiku is just called user, the new root user had a UID greater than 1000, not 0.
2. In the new Git package, the archive for sources-2 contains a directory entry for . that is owned by root:root. (In contrast, the first sources archive does not contain an entry for ., so its sources directory did not have its ownership changed)
3. Git now checks directory ownership, and claimed fatal: dubious ownership... during initialization.

(Likely we should also adjust HaikuPorter so that git-init failures display their proper error messages; and also to ignore the user/groups of tar archives entirely.)

[waddlesplash]

Also from @mmlr:

we should also generally disable extracting with other uids by means of filters
and probably heed the python tarfile docs warning about using data filter to prevent tars from writing anywhere in the system...

[waddlesplash]

I wonder why we use Python's tar handling support anyway. It appears all the things we do with it can be done via tar command line arguments, and we already use command line tools for extracting other types of archives. That'd be a lot simpler than all the code we have for filters and info-handling.

[waddlesplash]

It appears tar can only duplicate hardlinked files, though, not turn them into symlinks as our filtering code does. I think that should be fine?

[korli]

I suppose, that, when cross-building, the provided tar version can be very different.

[pulkomandy]

I think that should be fine?

Probably not, if the build modifies any of these files. It's difficult to say if some recipes would hit that specific problem.

In 2019, some build (@mmlr believes it to be https://build.haiku-os.org/buildmaster/master/x86_64/?buildrunDir=2953&viewMode=expanded) created a user named root. As the root user on Haiku is just called user, the new root user had a UID greater than 1000, not 0.

How did that even affect the builder? Creating a user should change the /etc/passwd file inside the chroot, but not the one used by the OS, right? So once the build is done, that user disappears? Otherwise, it is a chroot leak and that is a problem that should be solved on Haiku side?

[waddlesplash]

Otherwise, it is a chroot leak and that is a problem that should be solved on Haiku side?

The useradd command does not modify /etc/passwd but contacts Registrar to ask it to make the change. And registrar only checks that the application making the request is running as root (UID 0) and nothing else, which it is inside the chroot. Yes, we should probably fix this on the Haiku side, but I'm not quite sure about how.