Closed EricLin0509 closed 1 month ago
Regarding /dev/pts0
: Yes, I also have the rule /dev/pts/@{int} rw,
in my /etc/apparmor.d/local/pacman
file (but haven't had the time for a commit yet).
Regarding the other issue: that's the expected behavior. The pacman profile contains the rules:
# Read packages files
@{user_pkg_dirs}/**/ r,
@{user_pkg_dirs}/**.pkg.tar.zst{,.sig} r,
and @{user_pkg_dirs}
is defined in /etc/apparmor.d/tunables/home.d/apparmor.d
. In order to personalize this rule please follow the instructions here. As an alternative you could also add a rule like @{user_cache_dirs}/{paru/clone,yay}/**.pkg.tar.zst{,.sig} r,
to /etc/apparmor.d/local/pacman
.
This is more complex than it sounds. The problem is not about pacman but about any AUR helper (and makepkg), they use profiled programs during package build time and therefore, they require access to they own internal directories.
The solution needs to come with a dedicated profile for those profiles. However, as a makepkg, can build anything, anyhow it is... complex to have a profile that can fit into it. Furthermore, from a security point of view it would make more sense to simply sandbox the build.
The easy solution is to come with an unconfined profile to ensure it the build program does not conflict with the other profiles (I have this solution in place myself for some programs).
As a side effect, this would also fix #404
I used yay to install an app, but it failed. Because compiler had no permission to that file to compile it unless set to complain mode. Here is the log: