Re: Unable to determine UID of the request whan adding a connection.

2022-05-17 Thread Fr�d�ric Martinsons via networkmanager-list
Ok I see and these dbus call can fail silently (no error propagation), the 
timeout hypothesis seems to match my cases.
Changing to dbus-broker is indeed a big step for our system for such a low 
frequency issue we have.

Thanks for all the info Thomas.

From: Thomas Haller 
Sent: Tuesday, May 17, 2022 10:49 AM
To: Fr�d�ric Martinsons ; 
networkmanager-list@gnome.org 
Subject: Re: Unable to determine UID of the request whan adding a connection.

CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize the 
sender and know the content is safe.

On Tue, 2022-05-17 at 08:34 +, Fr�d�ric Martinsons wrote:
> Thank you for your quick response.
>
> > NetworkManager usually will authenticate the request using
> > PolicyKit.
> > -- unless, you set [main].auth-polkit in `man NetworkManager.conf`
> > or
> > make the request as root user.
> >
> > You say you don't use PolicyKit, so you set `[main].auth-
> > polkit=false`?
> >
>
> I compile NM with --disable-polkit configure option but I used a
> custom NetworkManager.conf with didn't have [main].auth-polkit =
> false. I'll add it to be sure it is not used.

That merely changes the compile time default to set `[main].auth-
polkit=false` implicitly. The PolicyKit code is always build, because
it has no additional dependency (just talking D-Bus). But this is fine.

>
>
> > The UID NetworkManager gets from dbus-daemon. It's not clear why
> > that
> > would fail. I presume, this is dbus-daemon, not dbus-broker?
>
> Yes, this is dbus-daemon.

ACK.

>
> > Are you using `hidepid` mount option for procfs? It should also
> > work
> > with that, but it could cause problems.
>
> Nope, just rw, relatime

ACK. Fine.

>
> > Or maybe you could run it under strace? However, that might be and
> > overwhelming amount of information. I'd try patching the source and
> > do
> > some printf debugging.
>
> Yes, I already patch nm-dbus-manager.c to know exactly where it fails
> but since then, I didn't manage to reproduce the issue after
> countless attempts.
>
> The fact that the completion took 4s on error case is not of any help
> to pinpoint where it fails ?

We get the caller info (UID and PID) via D-Bus calls
GetConnectionUnixUser and GetConnectionUnixProcessID (see
_get_caller_info_ensure()). Both blockingly, with a timeout of 2
seconds (which would add up to 4 seconds).

Maybe dbus-daemon does not reply in time? It's ugly that these calls in
NetworkManager are done blockingly, but even so, we heavily rely on
basic IPC to work, and if it's not working it's not clear how to
proceed there.

If that's the case, I don't know a solution. Trying dbus-broker is
probably too much of an invasive change?


Thomas



Your privacy is important to us. Please see our Privacy 
Notice for further 
details. The information contained in this Message is confidential. If you are 
not the addressee, you may not copy, forward, disclose or use any part of it. 
If you have received this Message in error, please delete it and all copies 
from your system and notify the sender immediately by return message. Any use 
of information contained in this Message not in accordance with its intended 
purpose, any dissemination or disclosure (either whole or partial), is 
prohibited unless expressly authorized. Email communication cannot be 
guaranteed to be timely secure, error or virus-free. The sender cannot be held 
responsible for any alteration, errors or omissions, which arise as a result.

..

La protection de vos données personnelles est primordiale pour notre 
établissement. Merci de consulter notre notice sur la protection des données 
personnelles  pour plus 
d’informations. Ce message et toutes les pièces jointes (ci-après le 'Message') 
sont établis à l'intention exclusive des destinataires. Les informations qui y 
figurent sont confidentielles. Si vous n'êtes pas le destinataire de ce 
Message, il vous est interdit de le copier, de le faire suivre, de le divulguer 
ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci 
de le supprimer de votre système, ainsi que toutes ses copies, et de n'en 
garder aucune trace sur quelque support que ce soit. Veuillez également en 
avertir immédiatement l'expéditeur par retour du Message. Toute utilisation de 
ce Message non conforme à sa destination, toute diffusion ou toute publication 
totale ou partielle, est interdite sauf autorisation expresse. Il est 
impossible de garantir que les communications par messagerie électronique 
arrivent en temps utile, soient sécurisées ou dénuées de toute erreur ou virus. 
L'expéditeur ne peut être tenu responsable des modifications, erreurs ou 
omissions qui pourraient en résulter.
___

Re: Unable to determine UID of the request whan adding a connection.

2022-05-17 Thread Thomas Haller via networkmanager-list
On Tue, 2022-05-17 at 08:34 +, Fr�d�ric Martinsons wrote:
> Thank you for your quick response.
> 
> > NetworkManager usually will authenticate the request using
> > PolicyKit.
> > -- unless, you set [main].auth-polkit in `man NetworkManager.conf`
> > or
> > make the request as root user.
> >  
> > You say you don't use PolicyKit, so you set `[main].auth-
> > polkit=false`?
> > 
> 
> I compile NM with --disable-polkit configure option but I used a
> custom NetworkManager.conf with didn't have [main].auth-polkit =
> false. I'll add it to be sure it is not used.

That merely changes the compile time default to set `[main].auth-
polkit=false` implicitly. The PolicyKit code is always build, because
it has no additional dependency (just talking D-Bus). But this is fine.

> 
> 
> > The UID NetworkManager gets from dbus-daemon. It's not clear why
> > that
> > would fail. I presume, this is dbus-daemon, not dbus-broker?
> 
> Yes, this is dbus-daemon.

ACK.

> 
> > Are you using `hidepid` mount option for procfs? It should also
> > work
> > with that, but it could cause problems.
> 
> Nope, just rw, relatime

ACK. Fine.

> 
> > Or maybe you could run it under strace? However, that might be and
> > overwhelming amount of information. I'd try patching the source and
> > do
> > some printf debugging.
> 
> Yes, I already patch nm-dbus-manager.c to know exactly where it fails
> but since then, I didn't manage to reproduce the issue after
> countless attempts.
> 
> The fact that the completion took 4s on error case is not of any help
> to pinpoint where it fails ?

We get the caller info (UID and PID) via D-Bus calls
GetConnectionUnixUser and GetConnectionUnixProcessID (see
_get_caller_info_ensure()). Both blockingly, with a timeout of 2
seconds (which would add up to 4 seconds).

Maybe dbus-daemon does not reply in time? It's ugly that these calls in
NetworkManager are done blockingly, but even so, we heavily rely on
basic IPC to work, and if it's not working it's not clear how to
proceed there.

If that's the case, I don't know a solution. Trying dbus-broker is
probably too much of an invasive change?


Thomas


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Unable to determine UID of the request whan adding a connection.

2022-05-17 Thread Fr�d�ric Martinsons via networkmanager-list
Thank you for your quick response.

> NetworkManager usually will authenticate the request using PolicyKit.
> -- unless, you set [main].auth-polkit in `man NetworkManager.conf` or
> make the request as root user.
>
> You say you don't use PolicyKit, so you set `[main].auth-polkit=false`?
>

I compile NM with --disable-polkit configure option but I used a custom 
NetworkManager.conf with didn't have [main].auth-polkit = false. I'll add it to 
be sure it is not used.


> The UID NetworkManager gets from dbus-daemon. It's not clear why that
> would fail. I presume, this is dbus-daemon, not dbus-broker?

Yes, this is dbus-daemon.

> Are you using `hidepid` mount option for procfs? It should also work
> with that, but it could cause problems.

Nope, just rw, relatime

> Or maybe you could run it under strace? However, that might be and
> overwhelming amount of information. I'd try patching the source and do
> some printf debugging.

Yes, I already patch nm-dbus-manager.c to know exactly where it fails but since 
then, I didn't manage to reproduce the issue after countless attempts.

The fact that the completion took 4s on error case is not of any help to 
pinpoint where it fails ?


From: Thomas Haller 
Sent: Tuesday, May 17, 2022 9:36 AM
To: Fr�d�ric Martinsons ; 
networkmanager-list@gnome.org 
Subject: Re: Unable to determine UID of the request whan adding a connection.

CAUTION: EXTERNAL EMAIL. Do not click links or open unless you recognize the 
sender and know the content is safe.

On Tue, 2022-05-17 at 06:51 +, Fr�d�ric Martinsons via
networkmanager-list wrote:
> Hello,
> I used NM 1.32.12 in an embedded environment, I have another daemon
> which is responsible for creating and monitoring connection profiles
> via libnm. I recently experienced errors I cannot understand, I
> received an error "Unable to determine UID of the request" in the
> completion callback of nm_client_add_connection_async.
>
> Looking at the code , it leads to this function
> (https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/
> 1.32.12/src/core/nm-dbus-manager.c#L1580) that return NULL.

NetworkManager usually will authenticate the request using PolicyKit.
-- unless, you set [main].auth-polkit in `man NetworkManager.conf` or
make the request as root user.

You say you don't use PolicyKit, so you set `[main].auth-polkit=false`?

NetworkManager needs to find out information about the calling process,
which usually means that the process needs to stick around long enoug
(you cannot just make the D-Bus request and quit before waiting for the
response). This is especially the case with PolicyKit enabled, but it
probably is also the case for other reasons. Well, it seems your client
tool is waiting for the D-Bus reply, so that isn't the problem.

Are you using `hidepid` mount option for procfs? It should also work
with that, but it could cause problems.

The UID NetworkManager gets from dbus-daemon. It's not clear why that
would fail. I presume, this is dbus-daemon, not dbus-broker?

I don't know what would cause it. If you don't see sufficient
information with full `level=TRACE` logs (see [1]), then maybe you
could build NM from source, and add additional print messages?

[1] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27

Or maybe you could run it under strace? However, that might be and
overwhelming amount of information. I'd try patching the source and do
some printf debugging.


good luck,
Thomas

>
> src/core/nm-dbus-manager.c · 1.32.12 · NetworkManager /
> NetworkManager
> NetworkManager — network management daemon
> gitlab.freedesktop.org
>
> The problem is there are no error/warning logs in NM which could help
> me to understand (so I guess the various g_return_val_if_fail used in
> the function are not reached). The only difference I see (beside the
> error of course) is the completion time between the async request and
> its response in my daemon (roughly 4 seconds in case of error instead
> of practically instant).
>
> From what I understand, it is related to authorization check but
> before this error, my daemon managed to create a NMClient and perform
> various getter on it.
> Several things that I can add for information:
>   - The system does not use polkit.
>   - NM runs as root and the client runs as a limited user.
>   - The problem is pretty hard to reproduce (see this two times on
> several thousand of the same sequence).
>
> Can you please give advice on how I can investigate more on that ?
> Maybe some particular traces to activate ?
>
> Thank you very much in advance for all the help you can bring.


Your privacy is important to us. Please see our Privacy 
Notice for further 
details. The information contained in this Message is confidential. If you are 
not the addressee, you may not copy, forward, disclose or use any part of it. 
If you 

Re: Unable to determine UID of the request whan adding a connection.

2022-05-17 Thread Thomas Haller via networkmanager-list
On Tue, 2022-05-17 at 06:51 +, Fr�d�ric Martinsons via
networkmanager-list wrote:
> Hello,
> I used NM 1.32.12 in an embedded environment, I have another daemon
> which is responsible for creating and monitoring connection profiles
> via libnm. I recently experienced errors I cannot understand, I
> received an error "Unable to determine UID of the request" in the
> completion callback of nm_client_add_connection_async.
> 
> Looking at the code , it leads to this function
> (https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/
> 1.32.12/src/core/nm-dbus-manager.c#L1580) that return NULL.

NetworkManager usually will authenticate the request using PolicyKit.
-- unless, you set [main].auth-polkit in `man NetworkManager.conf` or
make the request as root user.

You say you don't use PolicyKit, so you set `[main].auth-polkit=false`?

NetworkManager needs to find out information about the calling process,
which usually means that the process needs to stick around long enoug
(you cannot just make the D-Bus request and quit before waiting for the
response). This is especially the case with PolicyKit enabled, but it
probably is also the case for other reasons. Well, it seems your client
tool is waiting for the D-Bus reply, so that isn't the problem.

Are you using `hidepid` mount option for procfs? It should also work
with that, but it could cause problems.

The UID NetworkManager gets from dbus-daemon. It's not clear why that
would fail. I presume, this is dbus-daemon, not dbus-broker?

I don't know what would cause it. If you don't see sufficient
information with full `level=TRACE` logs (see [1]), then maybe you
could build NM from source, and add additional print messages?

[1] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27

Or maybe you could run it under strace? However, that might be and 
overwhelming amount of information. I'd try patching the source and do
some printf debugging.


good luck,
Thomas

> 
> src/core/nm-dbus-manager.c · 1.32.12 · NetworkManager /
> NetworkManager
> NetworkManager — network management daemon
> gitlab.freedesktop.org
> 
> The problem is there are no error/warning logs in NM which could help
> me to understand (so I guess the various g_return_val_if_fail used in
> the function are not reached). The only difference I see (beside the
> error of course) is the completion time between the async request and
> its response in my daemon (roughly 4 seconds in case of error instead
> of practically instant).
> 
> From what I understand, it is related to authorization check but
> before this error, my daemon managed to create a NMClient and perform
> various getter on it.
> Several things that I can add for information:
>   - The system does not use polkit.
>   - NM runs as root and the client runs as a limited user.
>   - The problem is pretty hard to reproduce (see this two times on
> several thousand of the same sequence).
> 
> Can you please give advice on how I can investigate more on that ?
> Maybe some particular traces to activate ?
> 
> Thank you very much in advance for all the help you can bring.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list