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@imx6quad:/$ echo $UID 997 Le jeu. 2 déc. 2021 à 13:55, Mohamed Ali Fodha <fodha.mohamed....@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....@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 >>> >>> >>> >>>
