<div dir="ltr">According to this thread <a href="https://github.com/systemd/systemd/issues/11034">https://github.com/systemd/systemd/issues/11034</a>, kdbus can manage linux capabilities but dbus can't, isn't it?<div><div>Below is what I did in my binary</div><div><br></div><div><i> r = sd_bus_open_system(&bus);<br> if (r < 0) {<br>         sm_error("Failed to connect to system bus\n");<br> }<br><br> r = sd_bus_call_method(bus,<br>         "org.freedesktop.systemd1",     <br>         "/org/freedesktop/systemd1",      <br>         "org.freedesktop.systemd1.Manager",  <br>         "StartUnit",                   <br>         &error,                            <br>         &m,                                  <br>         "ss",                                <br>         "reboot.target",                    <br>         "replace-irreversibly");</i><br></div><div><br></div><div>This call returns -13 (<span class="gmail-com" style="box-sizing:border-box;margin:0px;padding:0px;color:rgb(136,0,0)">#define</span><span class="gmail-pln" style="box-sizing:border-box;margin:0px;padding:0px">     EACCES          </span><span class="gmail-lit" style="box-sizing:border-box;margin:0px;padding:0px;color:rgb(0,102,102)">13</span><span class="gmail-pln" style="box-sizing:border-box;margin:0px;padding:0px"> </span><span class="gmail-com" style="box-sizing:border-box;margin:0px;padding:0px;color:rgb(136,0,0)">/* Permission denied */)</span></div><div>Below are the capabilities of the binary (hwmanager is called by regular user)<br></div><div><br></div><div><i>root@imx6quad:~# getcap /usr/sbin/hwmanager</i></div><div><i>/usr/sbin/hwmanager  = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_kill,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_rawio,cap_sys_admin,cap_sys_boot,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_syslog+eip<br></i></div><div><br></div><div>Mohamed Ali</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 1 déc. 2021 à 11:38, Ulrich Windl <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>>> Martin Wilck <<a href="mailto:mwilck@suse.com" target="_blank">mwilck@suse.com</a>> schrieb am 01.12.2021 um 10:41 in Nachricht<br>
<<a href="mailto:a64771271a667804c450a13481cee06180965b12.camel@suse.com" target="_blank">a64771271a667804c450a13481cee06180965b12.camel@suse.com</a>>:<br>
> On Wed, 2021‑12‑01 at 10:24 +0100, Ulrich Windl wrote:<br>
>> > > <br>
>> <br>
>> And I wonder what's wrong with allowing the shutdown command for the<br>
>> user in<br>
>> sudoers.<br>
>> (sudo $(which shutdown) ‑r now)<br>
> <br>
> Sure. I thought sudo might not be installed on that embedded system,<br>
> either. If it is, I'd prefer it over other solutions simply because<br>
> it's more transparent. Capability bits tend to go unnoticed.<br>
> <br>
<br>
Quote from OP: "Previously the guest user was in sudoers (so to run reboot the<br>
systemd<br>
service uses "sudo") but actually our customer wants to remove the guest<br>
user from sudoers."<br>
<br>
It was some odd security debate: If someone can operate as guest he/she should<br>
not be able to reboot, while the guest user should be.<br>
(Maybe I misunderstood. Any case some details for the problem are missing)<br>
<br>
<br>
> Martin<br>
<br>
<br>
<br>
</blockquote></div>