| 19 Jun 2026 |
 magic_rb | Oh so its checking the capability of the thread in the root ns, not the threads ns | 16:08:15 |
| magic_rb | (I mean thats an easy patch :P) | 16:08:21 |
| magic_rb | (Would also solve the gamescope RT issue) | 16:08:31 |
 K900 | It won't no | 16:08:40 |
| K900 | That's a different issue | 16:08:44 |
| magic_rb | Is it? If gamescope had valid cap_sys_nice when launched from steam as custom command, it could renice itself | 16:09:18 |
 ElvishJerricco | would relaxing that actually be safe? Like, presumably that cap exists to guard a user against doing these things; being able to bypass it just by entering a userns sounds like probably not something to allow | 16:09:21 |
| magic_rb | I run into that on my desktop | 16:09:23 |
| K900 | In reply to @magic_rb:matrix.redalder.org
Is it? If gamescope had valid cap_sys_nice when launched from steam as custom command, it could renice itself The global check cannot be changed | 16:09:43 |
| K900 | The change needs to be local to amdgpu if anything | 16:09:50 |
| K900 | And then it won't get CAP_SYS_NICE | 16:09:57 |
 Marie | so basically our options are apply the kernel patch or wait for valve to solve it because they have the same problem with steamrt3? :( | 16:09:59 |
| K900 | It should really use rtkit for that | 16:10:07 |
| magic_rb | I mean if i understand it correctly, you cant just give yourself cap_sys_nice even inti a userns | 16:10:14 |
| magic_rb | It shouldn't be changed :P | 16:10:23 |
| K900 | Like we have an existing mechanism for getting RT priority without capabilities | 16:10:28 |
| magic_rb | * | 16:10:35 |
| K900 | On the CPU side | 16:10:39 |
| K900 | And it's rtkit | 16:10:42 |
| magic_rb | And its called rtkit, yeah, should probably make a gamescope patch for that one instead | 16:10:53 |
| magic_rb | https://github.com/ValveSoftware/gamescope/issues/494
Ill open a new issue. What shall i say? If running gamescope in a userns cap_sys_nice wont work, as such the only option is rtkit?
| 16:12:52 |
| ElvishJerricco | you can. if you do unshare -U --keep-caps (to be clear, the more useful way to get it is unshare -r but -U --keep-caps moreso tells you what I'm talking about) you'll find that you have CAP_SYS_NICE. So relaxing that capable() call into ns_capable() call would mean that anyone could do it by doing unshare -U --keep-caps | 16:13:33 |
| ElvishJerricco | so whenever you patch the kernel to do a relaxation like that, you have to find a way to scope things so that whatever can be done in the namespace doesn't escape what the namespace was originally restricted to at its creation | 16:14:57 |
| magic_rb | What is -U? | 16:15:05 |
| ElvishJerricco | --user, make a user namespace | 16:15:13 |
| magic_rb | Ah | 16:15:16 |
| K900 | Honestly I'd probably not submit this without a patch | 16:15:19 |
| magic_rb | Yeah im looking at a patch, reading how to do rtkit | 16:15:33 |
| magic_rb | Doesnt look that hard | 16:15:35 |
| magic_rb | Ill write smth and open a draft PR to show i made an effort | 16:15:46 |
