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
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.
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(); if (r < 0) { sm_error("Failed to
connect to system bus\n"); } r =
>>> Martin Wilck schrieb am 01.12.2021 um 10:41 in Nachricht
:
> 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
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
>>> Martin Wilck schrieb am 01.12.2021 um 10:06 in Nachricht
:
> On Tue, 2021‑11‑30 at 14:11 +0100, Mohamed Ali Fodha wrote:
>> Thanks, but I think using setuid has a security risk for attackers,
>> so I understand there is no so much granularity to manage
>> unprivileged access to systemd in
On Tue, 2021-11-30 at 14:11 +0100, Mohamed Ali Fodha wrote:
> Thanks, but I think using setuid has a security risk for attackers,
> so I understand there is no so much granularity to manage
> unprivileged access to systemd in case the polkit is not used.
You could use setcap to set CAP_SYS_ADMIN
Thanks, but I think using setuid has a security risk for attackers, so I
understand there is no so much granularity to manage unprivileged access to
systemd in case the polkit is not used.
Best Regards,
Mohamed Ali
Le mar. 30 nov. 2021 à 13:00, Colin Guthrie a écrit :
> Mohamed Ali Fodha wrote
Mohamed Ali Fodha wrote on 30/11/2021 10:35:
Thank you for the answers, I am working on an embedded system and the
polkit is not installed (not enabled at all in yocto build).
I have a systemd service that run as a normal user and for some use case
it requires to do a reboot
I simulate it just
Thank you for the answers, I am working on an embedded system and the
polkit is not installed (not enabled at all in yocto build).
I have a systemd service that run as a normal user and for some use case it
requires to do a reboot
I simulate it just for now as a dbus-send as shown below (just for
Mantas Mikulėnas wrote on 30/11/2021 08:42:
On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha
mailto:fodha.mohamed@gmail.com>> wrote:
Hello,
I want to run reboot as normal user using the following command:
dbus-send --system --print-reply --reply-timeout=2000
On Tue, Nov 30, 2021 at 10:11 AM Mohamed Ali Fodha <
fodha.mohamed@gmail.com> wrote:
> Hello,
>
> I want to run reboot as normal user using the following command:
> dbus-send --system --print-reply --reply-timeout=2000 --type=method_call
> --dest=org.freedesktop.login1 /org/freedesktop/login1
Hello,
I want to run reboot as normal user using the following command:
dbus-send --system --print-reply --reply-timeout=2000 --type=method_call
--dest=org.freedesktop.login1 /org/freedesktop/login1
org.freedesktop.login1.Manager.Reboot boolean:false
but I got a Permission denied error.
I
13 matches
Mail list logo
