<div dir="ltr">Thanks, but I think using setuid has a security risk for attackers, so I understand there is no so much granularity to manage unprivileged access to systemd in case the polkit is not used.<div>Best Regards,</div><div>Mohamed Ali</div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 30 nov. 2021 à 13:00, Colin Guthrie <<a href="mailto:gmane@colin.guthr.ie">gmane@colin.guthr.ie</a>> a écrit : </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mohamed Ali Fodha wrote on 30/11/2021 10:35: > Thank you for the answers, I am working on an embedded system and the > polkit is not installed (not enabled at all in yocto build). > I have a systemd service that run as a normal user and for some use case > it requires to do a reboot > I simulate it just for now as a dbus-send as shown below (just for debug > - dbus-send will be replaced by a binary which will do the reboot) > Previously the guest user was in sudoers (so to run reboot the systemd > service uses "sudo") but actually our customer wants to remove the guest > user from sudoers. > Adding capabilities doesn't give me required permissions > > /[Service] > User=guest > ExecStart=dbus-send --system --print-reply > --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 > org.freedesktop.systemd1.Manager.StartUnit string:reboot.target > string:replace-irreversibly > AmbientCapabilities=CAP_SYS_BOOT CAP_SYS_ADMIN > CapabilityBoundingSet=CAP_SYS_BOOT CAP_SYS_ADMIN > / > /[Install] > WantedBy=multi-user.target/ If you will have a binary to do the commands then you should just do that. It has to be a proper compiled binary (e.g. a simple C program). Make sure the binary is owned by root and group-owned by the same group as your user (hopefully it has a private group) with group r+x permission. "Other" should be nothing to prevent abuse. Make sure the binary is marked as setuid. In the binary, ensure you call the appropriate commands to obtain root privs (setruid()/setuid() etc. - can't remember off hand what to use) Then simply exec out to "systemctl reboot". That way although your user calls the binary, the binary then has permission to become root and then "talk" to systemd to tell it to issue the reboot. Capabilities shouldn't come into I don't think as all you're doing is talking to systemd which does all the grunt work. HTHs Col -- Colin Guthrie gmane(at)<a href="http://colin.guthr.ie" rel="noreferrer" target="_blank">colin.guthr.ie</a> <a href="http://colin.guthr.ie/" rel="noreferrer" target="_blank">http://colin.guthr.ie/</a> Day Job: Tribalogic Limited <a href="http://www.tribalogic.net/" rel="noreferrer" target="_blank">http://www.tribalogic.net/</a> Open Source: Mageia Contributor <a href="http://www.mageia.org/" rel="noreferrer" target="_blank">http://www.mageia.org/</a> PulseAudio Hacker <a href="http://www.pulseaudio.org/" rel="noreferrer" target="_blank">http://www.pulseaudio.org/</a> Trac Hacker <a href="http://trac.edgewall.org/" rel="noreferrer" target="_blank">http://trac.edgewall.org/</a> </blockquote></div>