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

[Mohamed Ali Fodha]

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 at gmail.com>
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 at 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 at rz.uni-regensburg.de> a écrit :
>
>> >>> Martin Wilck <mwilck at suse.com> schrieb am 01.12.2021 um 10:41 in
>> Nachricht
>> <a64771271a667804c450a13481cee06180965b12.camel at suse.com>:
>> > 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
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211202/6069d826/attachment.htm>