Comment # 2 on bug 1225961 from Christian Boltz

(In reply to Fabian Vogt from comment #1)
> Looking at /etc/apparmor.d/plasmashell, it does mention QtWebEngineProcess
> but at a debian specific location, so that probably doesn't match and we can
> rule that out as cause.

It indeed doesn't match, but that doesn't rule it out - actually it's a pointer
to the issue.

> info="no new privs" is interesting: it means that the plasmashell process
> got no_new_privs set on it. I guess that might've been triggered by one of
> the plugins, maybe also WebEngine. That should by itself not prevent
> execution, but apparently with AppArmor it does?

no_new_privs gets set by the kernel if a process has an AppArmor profile.

You might have noticed that the rule for QtWebEngineProcess does cx ->
&plasmashell//QtWebEngineProcess,   instead of a simple cx to the child
profile. This means "profile stacking", which avoids that _more_ no_new_privs
restrictions get applied.

The   /** pux,   rule is meant for applications started by plasmashell, which
typically shouldn't get all those permissions.


That said - I submitted the fix for this (adding the openSUSE path) upstream as
https://gitlab.com/apparmor/apparmor/-/merge_requests/1248 and also submitted
an updated package to Tumbleweed.

If you want to test ASAP, you can pick the apparmor-profiles package from
security:apparmor as soon as the build finishes.