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. Best Regards, Mohamed Ali
Le mar. 30 nov. 2021 à 13:00, Colin Guthrie <gm...@colin.guthr.ie> a écrit : > 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)colin.guthr.ie > http://colin.guthr.ie/ > > Day Job: > Tribalogic Limited http://www.tribalogic.net/ > Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ > >
