https://bugzilla.suse.com/show_bug.cgi?id=1225961 https://bugzilla.suse.com/show_bug.cgi?id=1225961#c2 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christian Boltz <suse-beta@cboltz.de> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.