pipewire permission failures after the switch to run as non-root

Close for HH 8.0.0 release

Copying comment from gerrit 21750 so that it doesn't get lost:

 
Patch Set 2:

Patch Set 2:

With all 4 patches of the series applied I still get:

Jun 27 00:50:21 qemux86-64 audit[988]: AVC lsm=SMACK fn=smack_inode_permission action=denied subject="System::Pipewire" object="User::App::agl-service-audiomixer" requested=x pid=988 comm="pipewire" name="903" dev="proc" ino=22931 Jun 27 00:50:21 qemux86-64 audit[988]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7ffe8ddc96c0 a2=90900 a3=0 items=0 ppid=1 pid=988 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="pipewire" exe="/usr/bin/pipewire" subj=System::Pipewire key=(null) Jun 27 00:50:21 qemux86-64 audit: PROCTITLE proctitle="/usr/bin/pipewire" Jun 27 00:50:21 qemux86-64 pipewire[988]: [E][module-access.c:89 check_flatpak()] failed to open "/proc/903/root": Permission denied

Yes, this is all expected and harmless. We should find a way to suppress the log entries from the kernel and I should patch pipewire to downgrade that error message.

Essentially what happens is that pipewire is trying to assess whether the client is running in a containerized environment (flatpak), which is in fact not very different from our smack-based security confinement. In order to do that, it tries to access /proc/<client_pid>/root and it fails, which leads the detection code to correctly treat the client as a "flatpak" client. In practice this means that pipewire does not grant any permissions to that client and waits for the session manager to decide which objects should this client be able to see. This is also why I had to uprev wireplumber, which now has code to grant permissions to such restricted clients.

This is the target design, basically. Client should not be able to do anything until the session manager grants it access to some objects.

So eventually I am a bit stuck. I have thought of 2 ways to solve this.

1) When pipewire creates a memfd, patch it to also set the smack label of the memfd to the label of the peer process. This patch would be easy to do in pipewire (I looked up the code), but afaiu, a non-privileged process is not allowed to change the smack label of any kernel object, therefore, this patch won't work.

2) Let pipewire (& wireplumber) run with their own smack label (eg. System::Pipewire) and add the necessary rules in /etc/smack/accesses.d/ so that it has permission to access its modules and configuration file(s). This will also make the memfd to use this smack label, so the only thing remaining is to create a rule that will allow specific applications to read & write to objects with this smack label. For this to be implemented, we need a way to map an application permission (as specified in the widget xml file) to a smack rule that will be placed in /etc/smack/accesses.d/. So far I haven't been able to find how to do this.

Hmm, I thought it was working, but indeed the mediaplayer has issues. The problem seems to be that it cannot map the memory that is being sent to it by pipewire. The memory must be a memfd, so it has its own smack label as well, inherited from pipewire, so it's not enough to grant access to the socket.

Let me work on it a bit, it doesn't sound too hard to solve.

I did a test after pulling https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-devel/+/21703 and still no luck in mediaplayer on UP^2, attempting to play results in a bunch of permission failures.  Are there more changes coming?