| View previous topic :: View next topic |
| Author |
Message |
mschoenlaub
n00b
Joined: 14 Sep 2014
Posts: 1
|
 Posted: Sun Sep 14, 2014 4:05 pm Post subject: [SOLVED] Gnome 3.12, nm, gnome-keyring, libsecret |
 |
|
Hi,
getting Gentoo with Gnome and systemd and NetworkManager up and running went quite well so far 
Evolution automagically integrates with Gnome-Keyring/Seahorse, storing mail account passwords in the login keyring.
Only NetworkManager behaves quite strange. Googling around led me to some people having the same or quite similar problems, but most reports were from 2012 and remained unsolved.
However, before I started using Gentoo I've used Arch for some years, and there NetworkManager did happily store it's WPA-PSKs in the Gnome keyring, which led to me the assumption that I must have missed some configuration steps which might be done automatically in Arch.
Behaviour is as follows:
If I select a WIFI connection (or merely a found AP) via nm-applet, NetworkManager creates a system-wide connection (stored in /etc/NetworkManager/system-connections..) and even stores the PSK there. According to various bug reports for other distros this is the default behaviour for NM > 0.9.
If I select a WIFI connection (or merely a found AP) via nm-connection-editor, NetworkManager creates the same file (stored in /etc/NetworkManager/system-connections..), but does not store the PSK in this file. Additionally the line "permissions=user:XXX:;" indicates that this is a user-connection. Normally I would expect to find the PSK in my Gnome Keyring now. However, there it doesn't exist and consequently I am asked each and every time I connect to the AP for the PSK.
Editing the connection with nm-connection-editor I can see that the PSK is not stored.
However, the systemd journal shows no errors/warnings from NetworkManager. I've even turned on debug-level-logging for NetworkManager, but I cannot seem to find any traces of the interaction between Gnome keyring/seahorse and NetworkManager.
Regarding polkit configuration, I have modified to give everyone from wheel group admin permissions.
| Code: |
addAdminRule(function(action, subject) {
return ["unix-group:wheel"];
}); |
Okay.. some further research revealed the following:
As soon as I select a wireless AP via nm-applet it is deemed to be "system-wide", meaning its key is stored within "/etc/NetworkManager/system-connections".
When using nm-connection-editor to "create" the connection, the connection is established, but no keys are stored within my keyring (verified with seahorse).
Then, wehen using nm-connection-editor to edit the connection, systemd-journal reveals:
| Code: |
22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.681888] [nm-agent-manager.c:1112] nm_agent_manager_get_secrets(): Secrets requested for connection /org/freedesktop/NetworkManager/Settings/9 (802-11-wireless-security)
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.682053] [nm-agent-manager.c:620] request_add_agent(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent allowed for secrets request 0x7ad020/802-11-wireless-security
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.682080] [nm-settings-connection.c:864] nm_settings_connection_get_secrets(): (c782ce26-e7fd-45a2-ab5c-0446d9d409d1/802-11-wireless-security:43) secrets requested flags 0x4 hint '(null)'
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.682150] [nm-agent-manager.c:706] next_generic(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent getting secrets for request 0x7ad020/802-11-wireless-security
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.682398] [nm-agent-manager.c:988] get_next_cb(): (0x7ad020/802-11-wireless-security) requesting user-owned secrets from agent :1.211
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.688978] [nm-agent-manager.c:764] get_done_cb(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent returned no secrets for request 0x7ad020/802-11-wireless-security
Sep 14 22:46:40 zotac NetworkManager[14040]: <debug> [1410727600.689030] [nm-settings-connection.c:663] agent_secrets_done_cb(): (c782ce26-e7fd-45a2-ab5c-0446d9d409d1/802-11-wireless-security:43) secrets request error: (6) No agents were available for this request.
|
Having a quick look at the code for the GNOME Shell Network Agent (shell-network-agent.c, hopefully) indicates that this one should query the GNOME keyring. However, no (user-owned) key is found, so the dialog presents me an empty WPA2-PSK.
Upon filling in the WPA2 key in the dialog of nm-connection-editor, I assume the GNOME Shell Network Agent should store it in the keyring.
systemd journal says:
| Code: |
4 22:51:59 zotac NetworkManager[14040]: <debug> [1410727919.390811] [nm-agent-manager.c:1241] nm_agent_manager_save_secrets(): Saving secrets for connection /org/freedesktop/NetworkManager/Settings/9
Sep 14 22:51:59 zotac NetworkManager[14040]: <debug> [1410727919.390965] [nm-agent-manager.c:620] request_add_agent(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent allowed for secrets request 0x79e610/(null)
Sep 14 22:51:59 zotac NetworkManager[14040]: <debug> [1410727919.391116] [nm-agent-manager.c:706] next_generic(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent saving secrets for request 0x79e610/(null)
Sep 14 22:51:59 zotac NetworkManager[14040]: <debug> [1410727919.553081] [nm-agent-manager.c:1187] save_done_cb(): (:1.211/org.gnome.Shell.NetworkAgent/1000) agent saved secrets for request 0x79e610/(null)
|
However, no secrets are saved within the keyring. Furthermore, as soon as I use the connection via nm-applet it is "transformed" to a system-wide connection, storing the WPA2-PSK in an unencrypted file.
This is the DBUS-interaction between nm-connection-editor and (hopefully) the GNOME Shell Agent, it seems:
The first call apparently happens, when I open the connection settings (no secret is found, so input box for WPA2-PSK is empty)
| Code: |
method call sender=:1.15 -> dest=:1.9 serial=2298 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=SearchItems
array [
dict entry(
string "connection-uuid"
string "c782ce26-e7fd-45a2-ab5c-0446d9d409d1"
)
]
method return sender=:1.9 -> dest=:1.15 reply_serial=2298
array [
]
array [
]
|
The second one SHOULD create the secret in the keyring. The journalctl-logs say, that everything is okay (compare previous post). This indicates that somewhere probably no error checking is done, as in fact an error is returned from this call.
| Code: |
method call sender=:1.15 -> dest=org.freedesktop.secrets serial=2299 path=/org/freedesktop/secrets/aliases/default; interface=org.freedesktop.Secret.Collection; member=CreateItem
array [
dict entry(
string "org.freedesktop.Secret.Item.Attributes"
variant array [
dict entry(
string "setting-key"
string "psk"
)
dict entry(
string "setting-name"
string "802-11-wireless-security"
)
dict entry(
string "connection-uuid"
string "c782ce26-e7fd-45a2-ab5c-0446d9d409d1"
)
dict entry(
string "xdg:schema"
string "org.freedesktop.NetworkManager.Connection"
)
]
)
dict entry(
string "org.freedesktop.Secret.Item.Label"
variant string "Network secret for Tomato24/802-11-wireless-security/psk"
)
]
struct {
object path "/org/freedesktop/secrets/session/s5"
array of bytes [
51 02 fb 3c c1 ed 34 f3 b9 b1 c7 68 ff a3 92 ff
]
array of bytes [
13 c1 24 19 49 8b 42 fd 3b 81 6a a7 37 0b fc 09
]
string "text/plain"
}
boolean true
error sender=:1.9 -> dest=:1.15 error_name=org.freedesktop.DBus.Error.InvalidArgs reply_serial=2299
string "The secret was transferred or encrypted in an invalid way."
|
Hmm... GNOME is actually deprecating libgnome-keyring, but watch this:
| Code: |
* These packages depend on libsecret:
app-crypt/seahorse-3.12.2 (>=app-crypt/libsecret-0.16)
app-text/evince-3.12.1 (libsecret ? >=app-crypt/libsecret-0.5)
gnome-base/gnome-shell-3.12.2 (networkmanager ? app-crypt/libsecret)
gnome-base/gvfs-1.20.2 (libsecret ? app-crypt/libsecret)
gnome-extra/evolution-data-server-3.12.4 (>=app-crypt/libsecret-0.5[crypt])
gnome-extra/nm-applet-0.9.8.10-r1 (app-crypt/libsecret)
net-libs/gnome-online-accounts-3.12.4 (>=app-crypt/libsecret-0.5)
net-libs/webkit-gtk-2.4.4 (libsecret ? app-crypt/libsecret)
sys-apps/gnome-disk-utility-3.12.1 (>=app-crypt/libsecret-0.7)
|
| Code: |
* These packages depend on libgnome-keyring:
app-admin/system-config-printer-gnome-1.4.3-r1 (gnome-keyring ? gnome-base/libgnome-keyring[introspection])
dev-vcs/git-1.8.5.5 (gnome-keyring ? gnome-base/libgnome-keyring)
gnome-base/gnome-shell-3.12.2 (gnome-base/libgnome-keyring)
gnome-extra/nm-applet-0.9.8.10-r1 (gconf ? gnome-base/libgnome-keyring)
|
Solved the problem by unmerging gnome-base/libgnome-keyring (despite gnome-shell depends on it). Interaction started working as soon as libgnome-keyring was unavailiable.
Despite re-emerging libgnome-keyring (and gnome-shell, in case it forgot about libgnome-keyring) the system continued to work as expected
Unfortunately I am now not able to reproduce the error above anymore for a bug report. However, in the process of researching the cause of this error I looked at the source code of Gnome Shell, NetworkManager and nm-applet.
I see no reason why gnome-shell has a dependency for libgnome-keyring, as the only part which seems to use related function is the ShellNetworkAgent hooking up with NetworkManager. And this part has been migrated to libsecret (as most other, if not all official GNOME bits)
Last edited by mschoenlaub on Sun Sep 14, 2014 10:02 pm; edited 1 time in total |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
