The makepkg tool does use fakeroot, and the more robust wrapper for it used in the devtools package runs it in a container to have a consistent, isolated build environment. There's a source and package audit tool (namcap) which devtools runs before/after to catch SOME issues.
Conversation
It's unrealistic to catch any possible malicious thing that a package can do. Packages can have an arbitrary install script for creating their users/groups, etc. The namcap tool is meant to catch mistakes. It notifies about setuid/setgid binaries, some missing mitigations, etc.
2
Packages have no business creating users or groups or messing with any sort of system-level singletons.
1
That's how packages work on every traditional distribution though. They aren't isolated apps like an apk on Android. They get to install to every global directory and run arbitrary code in an install script. Installing to default bin / lib paths is arbitrary code exec anyway.
2
Thus:
Quote Tweet
Replying to @DanielMicay and @hackerfantastic
OK, I don't understand everything about how Arch/AUR does stuff, and I'll probably catch a bunch of other dists in this criticism too...
1
1
Even without an Android-like privilege model where apps are isolated from privileges of the invoking user, you can and should have a model where packages never have more privileges than any user who invokes their binaries (i.e. not root during install).
2
This property is needed in order for it to be safe for an administrator to install packages that a user has requested (and trusts) without the administrator also having to trust that package, and limits the damage to the user(s) who want it.
1
Needing an administrator to install packages globally that are in everyone's configuration / library / binary paths is a problem. It should be possible to install a package only for a specific user, even without having support for properly sandboxing everything.
1
2
I completely agree with this, but there may be advantages to having the admin install it (automated updates, single point of knowledge of what's installed, reproducing the setup without dependence on user files, ...).
1
1
nixos.org/nix/ has a compelling approach to these things and supports exposing package installations only to users that wanted to install the packages even though it is actually installed globally.
1
1
User A can request that the system install a package for them, and it doesn't get exposed to User B in PATH or any directories used by other packages. If User B installs the same package, it will reuse the same global installation. Packages are neatly separated, not all mixed.