| 19 Jun 2026 |
 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 |
| K900 | But user doesn't have cap_sys_nice normally | 16:17:11 |
| ElvishJerricco | doesn't matter | 16:17:21 |
| ElvishJerricco | when you make a user namespace, that namespace has all caps | 16:17:31 |
| magic_rb | Not cap_sys_admin? Or even that | 16:17:45 |
| magic_rb | What | 16:17:46 |
| ElvishJerricco | those caps just end up being restricted in kernel logic to not do things to escape the original caps | 16:17:52 |
| magic_rb | How can this shit be so fucking complicated and unintuitive | 16:17:55 |
| ElvishJerricco | even that | 16:18:00 |
| ElvishJerricco | e.g. | 16:18:08 |
| ElvishJerricco | the reason you can make mounts in a user namespace without CAP_SYS_ADMIN outside the namespace is because the user namespace allows you to make a mount namespace. So you make the user namespace, that namespace has CAP_SYS_ADMIN. You cannot use this CAP_SYS_ADMIN to make mounts yet, because that CAP_SYS_ADMIN is not allowed to make mounts in mount namespaces from its parent user namespace. So you make a new mount namespace, which user namespaces are allowed to do, and because it was made in your user namespace, and because you have CAP_SYS_ADMIN in that user namespace, you're allowed to make mounts in that mount namespace | 16:20:16 |
| ElvishJerricco | i.e. the same CAP_SYS_ADMIN has different capabilities depending on whether your userns owns the thing you're trying to use it on | 16:21:08 |
