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....@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@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.wi...@rz.uni-regensburg.de> a écrit :
>
>> >>> Martin Wilck <mwi...@suse.com> schrieb am 01.12.2021 um 10:41 in
>> Nachricht
>> <a64771271a667804c450a13481cee06180965b12.ca...@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
>>
>>
>>
>>
