Re: Antw: [EXT] Re: [systemd‑devel] Run reboot as normal user

[Mohamed Ali Fodha <fodha.mohamed.ali@xxxxxxxxx>]

After debug, the root cause comes from below code (bus-convenience.c):

   /* We cannot use augmented uid/euid for authorization,
    * since then data is acquired raceful from
    * /proc. This can never actually happen, but let's
    * better be safe than sorry, and do an extra check
    * here. */
    assert_return((sd_bus_creds_get_augmented_mask(creds) & (SD_BUS_CREDS_UID|SD_BUS_CREDS_EUID)) == 0, -EPERM);

Mohamed Ali

Le jeu. 2 déc. 2021 à 08:42, Mohamed Ali Fodha <fodha.mohamed.ali@xxxxxxxxx> a écrit :

According to this thread https://github.com/systemd/systemd/issues/11034, kdbus can manage linux capabilities but dbus can't, isn't it?

Below is what I did in my binary

 r = sd_bus_open_system(&bus);
 if (r < 0) {
         sm_error("Failed to connect to system bus\n");
 }

 r = sd_bus_call_method(bus,
         "org.freedesktop.systemd1",     
         "/org/freedesktop/systemd1",      
         "org.freedesktop.systemd1.Manager",  
         "StartUnit",                   
         &error,                            
         &m,                                  
         "ss",                                
         "reboot.target",                    
         "replace-irreversibly");

This call returns -13 (#define EACCES 13 /* Permission denied */)

Below are the capabilities of the binary (hwmanager is called by regular user)

root@imx6quad:~# getcap /usr/sbin/hwmanager

/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

Mohamed Ali

Le mer. 1 déc. 2021 à 11:38, Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> a écrit :

>>> Martin Wilck <mwilck@xxxxxxxx> schrieb am 01.12.2021 um 10:41 in Nachricht
<a64771271a667804c450a13481cee06180965b12.camel@xxxxxxxx>:
> On Wed, 2021‑12‑01 at 10:24 +0100, Ulrich Windl wrote:
>> > >
>>
>> And I wonder what's wrong with allowing the shutdown command for the
>> user in
>> sudoers.
>> (sudo $(which shutdown) ‑r now)
>
> Sure. I thought sudo might not be installed on that embedded system,
> either. If it is, I'd prefer it over other solutions simply because
> it's more transparent. Capability bits tend to go unnoticed.
>

Quote from OP: "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."

It was some odd security debate: If someone can operate as guest he/she should
not be able to reboot, while the guest user should be.
(Maybe I misunderstood. Any case some details for the problem are missing)


> Martin