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

[Mohamed Ali Fodha]

Sorry my previous analysis is wrong, the *sd_bus_query_sender_privilege*
return 0 due to check *if (sender_uid == our_uid)* and then the
*bus_verify_polkit_async
return -EACCES*;

if (sender_uid == our_uid)

(gdb) p sender_uid
$25 = 997
(gdb) p our_uid
$26 = 0

guest at imx6quad:/$ echo $UID

997

Le jeu. 2 déc. 2021 à 13:55, Mohamed Ali Fodha <fodha.mohamed.ali at gmail.com>
a écrit :

> 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/3bffd0f6/attachment-0001.htm>