Not sure for which component to report it so report here. Starting from plasma 5.25 launched from shortcuts applications have cap_sys_nice=eip capabilities while if you run them with krunner/launch menu they don't. This doesn't seem right. To reproduce launch konsole with shortcut and with krunner and check `capsh --current` or `getpcaps $$`. You will see: Current: cap_sys_nice=eip cap_setpcap+i Current IAB: cap_setpcap,^cap_sys_nice and Current: = Current IAB:
Issue in nixpkgs that can have additional details: https://github.com/NixOS/nixpkgs/issues/185582
kwin_wayland has CAP_SYS_NICE, and it is responsible for spawning applications via shortcuts on Wayland. So apparetly that capability is inherited/leaked to the spawned process
In nixos kwin_wayland had this capability since 5.12 release: https://github.com/NixOS/nixpkgs/commit/1de98e85681e7d1028fe866fa220c05ce1ed842f So it seems something changed in kwin that caused this.
According to this commit message it shouldn't leak this capability: https://github.com/KDE/kwin/commit/a601a08ba7a65ebb4df46cf1f94f3fff2c0553cd
(actually it's about realtime scheduling, so it looks like this commit caused this problem)
Just checked - reverting this commit fixes the problem.
> cap_sys_nice=eip capabilities Hmm, the fact that cap_sys_nice is in the inheritable set is unexpected.
What are the capabilities attached to kwin_wayland executable? --- I personally cannot reproduce this on my Arch machine, cap_sys_nice is not leaked to child processes on my machine unless I start manually adding +i
Can you also get capabilities attached to konsole?
~ ➜ getpcaps /var/run/wrappers/bin/kwin_wayland /var/run/wrappers/bin/kwin_wayland: cap_setpcap,cap_sys_nice=i konsole doesn't have capabilities.
Here how it's assigned in NixOS: https://github.com/NixOS/nixpkgs/blob/985524984f344a382519416f42f562eae165ddfb/nixos/modules/services/x11/desktop-managers/plasma5.nix#L255-L260
(In reply to Evgeny from comment #10) > ~ ➜ getpcaps /var/run/wrappers/bin/kwin_wayland > /var/run/wrappers/bin/kwin_wayland: cap_setpcap,cap_sys_nice=i I'm confused by this. You should see something like cap_sys_nice=ep. Also, getpcaps takes the pid instead of the filepath of the executable. Regardless, when providing a file path, you should see something like "/var/run/wrappers/bin/kwin_wayland: =". Does your distro add capabilities to the inherited set auto-magically?
> I'm confused by this. You should see something like cap_sys_nice=ep. Also, getpcaps takes the pid instead of the filepath of the executable. `getpcaps` can take file path, it seems in this case it's the same as `getcap`. But not sure how the output format should look like. Here is the output for kwin_wayland pid: ~ ➜ getpcaps 309072 309072: cap_setpcap,cap_sys_nice=i > Does your distro add capabilities to the inherited set auto-magically? It sets them to `ep`, see the link in my previous comment. Not sure, maybe inheritance is somehow implied by that.
Can you double-check that the distro doesn't do anything extra with capabilities? KWin is made to work with cap_sys_nice only in "ep" not "eip".
> I'm confused by this. You should see something like cap_sys_nice=ep. Actually `getcap` has this format: ~ ➜ getcap /run/wrappers/bin/kwin_wayland /run/wrappers/bin/kwin_wayland cap_setpcap,cap_sys_nice=ep > Can you double-check that the distro doesn't do anything extra with capabilities? KWin is made to work with cap_sys_nice only in "ep" not "eip". According to getcap it's ep, not eip. But I'm not sure, how else distro can affect it?
Found this change for gnome: https://github.com/NixOS/nixpkgs/commit/9742df15950a4c53e89fcc79feabd3a1a78827e2 so it indeed could be something with NixOS.
Here is original MR for gnome: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/460 It seems they had to deal with this too, though I'm not sure from where it gets inheritance.
Alright, there is already a fix with explanation: https://github.com/NixOS/nixpkgs/pull/185579 Thanks for looking into this anyway.