jeu. 2 déc. 2021 à 13:55, Mohamed Ali Fodha
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 ha
. */
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
a écrit :
> According to this thread https://github.com/systemd/systemd/issues/11034,
> kdbus can ma
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 =
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 wr
P_SYS_BOOT CAP_SYS_ADMIN*
*[Install]WantedBy=multi-user.target*
Thank,
Mohamed Ali
Le mar. 30 nov. 2021 à 10:37, Colin Guthrie a écrit :
> 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>
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
Hello,
I have unmounting issues during reboot as mentioned below for
*/etc/machine-id*
and */etc*, what could be the problem?
For information, after the boot I got an ID in /etc/machine-id
*[FAILED] Failed unmounting /etc/machine-id.*
[ OK ] Stopped Bind mount volatile /var/cache.
[ OK ]
Sat, Jun 27, 2020 at 11:30 PM Mohamed Ali Fodha <
> fodha.mohamed@gmail.com> wrote:
>
>> Hello,
>>
>> I noticed that mounting partition takes more time on yocto thud regarding
>> rocko.
>> I checked the dev-mmcblk0p2.device in my case using systemd-bootc
Hello,
I noticed that mounting partition takes more time on yocto thud regarding
rocko.
I checked the dev-mmcblk0p2.device in my case using systemd-bootchart.
Is there any reason why this mouting delay was increased?
Where the dev-mmcblk0p2.device comes from? I am not able to locate it in
