Modem authentication via the NM d-bus API - how to handle PUK?
- From: Sergey 'Jin' Bostandzhyan <jin mediatomb cc>
- To: networkmanager-list gnome org
- Subject: Modem authentication via the NM d-bus API - how to handle PUK?
- Date: Fri, 16 Oct 2020 14:32:24 +0200
Hi everyone,
I'd like to start a discussion about NetworkManagers SecretAgent D-Bus API
in relation to modem authentication.
What I could see so far is that the only thing one can provide to the modem
via NM is the PIN, that's it. PUK, PIN2, PUK2 are not known to NetworkManager
and remain completely unhandled.
This turned out to be quite combersome for applications that use NM's D-Bus
inteface to control the network. The only way I found so far was to go to
ModemManager directly and query the lock state so that I can figure out what
kind of code I need to send.
Further, if I provide the PIN in the GetSecrets response as part of the
Settings structure, it will simply get saved in the connection configuration in
/etc/NetworkManager/system-connections/
If I wanted to have it permanently on disk, I would have set it up prior to
connecting using the Update call on the Settings object, so this somewhat
uncontrolled saving is not necessarily nice... or am I missing something?
What is the currently "suggested" method of interacting with NM when it comes
to PUK entries, am I missing something or is there really no way to do it only
via NM?
I am also a bit confused about "hints" and the documentation stating that a
hint is just a hint.. shouldn't the underlying plugin know exactly which
credentials it needs and what it is requesting?
I would generally propose at looking at authentication outside the scope of
Settings. Basically, if settings support a certain auth type - that's fine and
the application can chose to set the password or pin and call Update to save
it permanently. However the "live" auth request call which is how I see
GetSecrets - which is anyway only triggered if the settings lack the desired
configuration - should rather tell the application exactly what credentials
for which connection and device are being requested and should pass those
to the underlying plugin, in the above PUK case to ModemManager, so that these
credentials get applied correctly. If NM is not aware of this setting as
part of its Settings object, that'd be still fine, NM would only act as a
proxy to the underlying plugin. The plugin in turn, knows what to do with the
received credentials and how to apply them to the device or connection.
So, how would I properly deal with this now and what do you think regarding
such an extension to the API as outlined above?
Kind regards,
Jin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]