Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible with proc hidepid=2? #9

Open
ivanbaldo opened this issue Jun 6, 2019 · 10 comments
Open

Incompatible with proc hidepid=2? #9

ivanbaldo opened this issue Jun 6, 2019 · 10 comments

Comments

@ivanbaldo
Copy link

ivanbaldo commented Jun 6, 2019

Hello.
I use /proc mounted with (among other options) hidepid=2,gid=133
In that group (named nohidepid) among others I have added the rtkit user.
It still doesn't work.
I tried

# cat /etc/systemd/system/rtkit-daemon.service.d/override.conf
[Service]
SupplementaryGroups=nohidepid

Doesn't work even after a reboot.
The privilege dropping seems to discard supplementary groups :-(
Thanks!

@heftig
Copy link
Owner

heftig commented Jun 7, 2019

Yes. Not sure how easy this is to fix. You might need to make your nohidepid group rtkit's main group.

@ivanbaldo
Copy link
Author

Yeah, of course, but still: that's a workaround, not a proper fix and behavior.
Thanks for your answer Jan!

@Maryse47
Copy link

Maryse47 commented Sep 8, 2019

This workaround doesn't actually work. Still Failed to look up client: No such file or directory.

@heftig
Copy link
Owner

heftig commented Sep 9, 2019

@Maryse47 Are you sure? What did you try?

So, I think the problem is that as part of "dropping privileges" (which can be disabled with --no-drop-privileges), rtkit-daemon changes its user and group but disregards supplementary groups (which get cleared).

PTRACE capability overrides hidepid, but I think this would give the daemon too many privileges. I think it's a better option to make it actually apply the supplementary groups for the rtkit user.

Seems it needs quite a bit of code to do that, though. I would prefer to kill all the privilege dropping and resource limits code from rtkit and add equivalent directives to the systemd service unit. Arch Linux would be fine with this, but I don't know if all my other downstreams would appreciate it.

@Maryse47
Copy link

@heftig I changed rtkit primary group to one used by hidepid, confirmed that daemon runs as user:rkit group:<hidpid_group> and still it spams in journal with Failed to look up client: No such file or directory after rtkit deamon starts. I tested it after reboot.

Honestly I wouldn't mind to get rid of rtkit altogether so if it's possible to make it optional dep for pulseaudio and pipewire and call incompatible with hidepid option it would be acceptable solution.

@marcthe12
Copy link

Seems it needs quite a bit of code to do that, though. I would prefer to kill all the privilege dropping and resource limits code from rtkit and add equivalent directives to the systemd service unit. Arch Linux would be fine with this, but I don't know if all my other downstream would appreciate it.

@heftig drop it or make it optional. This project is anyway on maintenance mode already so we should prob should simplify it so it is more maintainable.

@exuvo
Copy link

exuvo commented Dec 17, 2020

Is there no workaround for this other than disabling hidepid?

@Maryse47
Copy link

Maryse47 commented Dec 17, 2020

You can remove/disable rtkit if you don't need it.

@exuvo
Copy link

exuvo commented Dec 17, 2020

Unfortunately i do need it for pulseaudio and pulseeffects.

Looking at the code can it not be resolved by just sending in the proc group in rtkit-daemon.c:1762 if (setgroups(0, NULL) < 0 || ? That call clears all the supplementary groups right now.

@exuvo
Copy link

exuvo commented Dec 18, 2020

I just recompiled with the following change and i can now use hidepid=2,gid=proc with rtkit working. Group proc has id 26 on my system.

At rtkit-daemon.c:1762

id_t groups[1] = { 26 };
if (setgroups(1, groups) < 0 ||

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants