initializing gnome-keyring-daemon in autostart

xaos52 · 2016-01-31 10:11:47

^ Seems like it won't be dropped after all because it provides some useful features.

John wrote:

So I think if we're going to keep gnome-keyring the way to initialize it in openbox/autostart might be:

We are just struggling a bit now to get it set up correctly to function under openbox.

Tao · 2016-01-31 10:36:26

Is responsible for what each of its components? Passwords for websites?

hhh · 2016-01-31 18:19:35

Tao wrote:

Passwords for websites?

No, your browser handles that.

https://support.mozilla.org/en-US/kb/pa … and-import
https://support.google.com/chrome/answer/95606?hl=en

gnome-keyring is supposed to "just work" OOTB with LightDM...
https://wiki.gnome.org/action/show/Proj … omeKeyring
https://wiki.archlinux.org/index.php/GNOME_Keyring

-edit- Is there anything here that helps?
https://wiki.gnome.org/Projects/GnomeKe … ningDaemon
https://wiki.gnome.org/Projects/GnomeKe … stributors

hhh · 2016-01-31 19:51:46

^Sorry, those points are all covered earlier in the thread. :8

xaos52 · 2016-02-01 03:19:31

Edited post #19

@John,
Do you still have access to the crunchbang source repo, can you verify this and make the source of thet 'crunchified lxsession' available?
If not we will have to create one ourselves.

hhh · 2016-02-01 05:39:42

I don't understand, there was no lxsession package in Waldorf.

xaos52 · 2016-02-01 09:06:43

I am not sure when lxsession was left out of crunchbang.
Not even sure if 'lxsession' was the name of the package. Perhaps lxsession-lite or something?
But I am sure it was there when I joined crunchbang.

See this post and its context.

johnraff · 2016-02-02 04:27:18

A few different points came up. I'll try to respond in order:

*) We should have an all-round consensus, but considering the problems caused to new users by not having gnome-keyring are potentially worse, and more mysterious, than for those who have it but don't use it, then maybe as a "full featured" setup like #!, we should include it - and try our best to get it set up nicely... Of course, there would also be no harm in adding it to a list of "Stuff you can perhaps safely remove" on the forum somewhere.

*) /usr/lib/x86_64-linux-gnu/openbox-xdg-autostart seems to be doing its job OK on my systems. The processes which are auto-started are consistent with the contents of the .desktop files in /etc/xdg/autostart. @xaos52 did you start openbox in debug mode to see that error?

*) /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 is a quite different issue. Anyone who installs an auto-updating menu will find that a couple of things - synaptic for example - are not started properly. This is because the associated .desktop files in /usr/share/applications call for pkexec instead of gksu. The above service will open a polkit authentication window in such cases. I think the password window that opens when permission is needed to mount a hard drive is also coming from there. @tknomanzr you were able to enter polkit passwords OK without it?

*) $GNOME_KEYRING_CONTROL is not being set. I don't know why, or what problems that might be causing. More googling...

*) lxsession-lite was in the #! Statler system but as far as I could tell at the time it exited immediately, doing nothing (as you also found @xaos52). I have a copy of the Waldorf package repo, but not Statler unfortunately. I don't think there was a special "crunchified" version, and anyway by Waldorf it had been dropped with no apparent problems so I'd be surprised if it was the answer here.

tknomanzr · 2016-02-02 08:51:05

I honestly had no idea why the original gnome keyring lines were there. I simply copied them over from Crunchbang and went with that. I remember being surprised when I saw you had added the line for policykit. However it does make sense in retrospect for a couple of reasons:

1. I don't use Synaptic at all and in fact during that period of time I recall it was crashing. It is my belief that we thought there was a themeing issue going on at the time but it is very likely that I was not using it correctly in regards to policykit. As I said, I don't really use the software so my testing of it was pretty low priority at the time.
2. Back then, I was using pretty broad permissions in policykit. I didn't start refining the defaults that came from Crunchbang down til later, so it is likely I would not have bumped into a permission failure issue. However, I have seen those issues posted both on the #! forums and elsewhere on the web.

Keyrings can be nice but come with their own security considerations when you have physical access to a machine. I know the OSX machines at work, I would regularly dig up email passwords from the OSX keyring. It also stored a bunch of other stuff like website passwords, etc. that seemed problematic to me. I have no idea how Gnome's keyring works but if it comes with a GUI that present information in human readable form, that could be somethhing to consider.

Also consider that in addition to ~/.config/openbox and /etc/xdg/autostart, stuff can be automatically started as a systemd service. All you really need is a proper unit file and also, if one is not present a rules file. I am thinking about stuff like automounting sshfs shares and stuff that can be achieved at startup via a unit file per Arch wiki examples.

xaos52 · 2016-02-02 11:04:04

*) /usr/lib/x86_64-linux-gnu/openbox-xdg-autostart seems to be doing its job OK on my systems. The processes which are auto-started are consistent with the contents of the .desktop files in /etc/xdg/autostart. @xaos52 did you start openbox in debug mode to see that error?

I found the explanation for that one.
I m not rebooting when doing my tests.
Just switching to a VC and stopping X with 'systemctl isolate multi-user.target', then restarting X with 'systemctl isolate graphical.target'
When you do it like that the xdg startup mechanism tries to start some processes already running, which produces the error.

xaos52 · 2016-02-02 19:39:29

I can now categorically state that $HOME/.config/openbox $HOME/.config/openbox/autostart is not the right place to set and export variables that you want to be present in every openbox child process.

This time I have checked and double checked!

You can test this yourself easily by editing $HOME/.config/openbox/autostart, insert this line

export THIS_IS_A_TEST="This is a test"

anywhere in the file and restart X or reboot.

After reboot start a terminal and verify that THIS_IS_A_TEST is not in the environment.

I did make some progress in using gnome-keyring:

Configuring iceweasel to store site passwords in a keyring works. I will write more about that tomorrow.
I could not make NetworkManager or nm-applet to store my WPA wifi keyword in the keyring.

EDIT
PATH in first line

johnraff · 2016-02-03 04:43:45

xaos52 wrote:

I can now categorically state that $HOME/.config/openbox is not the right place to set and export variables that you want to be present in every openbox child process.
This time I have checked and double checked!
You can test this yourself easily by editing $HOME/.config/openbox, insert this line
export THIS_IS_A_TEST="This is a test"
anywhere in the file and restart X or reboot.

@Dr Xaos, there is no file $HOME/.config/openbox so if you created one then it certainly wouldn't have been read by openbox. Did you do your test in $HOME/.config/openbox/autostart or perhaps $HOME/.config/openbox/environment? The latter, in default BL, contains the line

export XDG_CURRENT_DESKTOP=XFCE

and, at least on my test VM system, XDG_CURRENT_DESKTOP is in the environment, confirmable from a terminal.

------

I'm just about to startup my test laptop and see what Network Manager is doing with passwords.

johnraff · 2016-02-03 04:54:33

tknomanzr wrote:

I know the OSX machines at work, I would regularly dig up email passwords from the OSX keyring. It also stored a bunch of other stuff like website passwords, etc. that seemed problematic to me. I have no idea how Gnome's keyring works but if it comes with a GUI that present information in human readable form, that could be somethhing to consider.

My understanding of gnome-keyring is that passwords (or gpg keys, notes etc) are stored on the disk in encrypted form in "keyrings" that can only be opened by a user-entered password. Opened keyrings are held in memory, not on disk. There is one special keyring, called "login" which is opened by the same password, and at the same time, as the user login via LightDM (or any other DM that works with gnome-keyring).

This means that when a user is not logged in their passwords should be safe. Once you log in, however, anything stored in your "login" keyring is available, and can be viewed by the GUI "Seahorse" for example. If you try to view passwords in a different keyring than "login", you will be prompted for the (different) password to open it.

So locking the screen when you leave a logged-in session unattended is important!

johnraff · 2016-02-03 07:30:47

xaos52 wrote:

I did make some progress in using gnome-keyring:
Configuring iceweasel to store site passwords in a keyring works. I will write more about that tomorrow.

Please! That might be more secure than letting iceweasel store them I guess?

I have successfully set up a WiFi connection on NetworkManager with no password stored in plain text, as it was before. I'm presuming (hoping) this means it is safely stored in gnome-keyring's "login" keyring.

Anyone who wants to try, this is what I did:
(assuming you have a wireless connection already set up through Network Manager)

*) Open (as root) /etc/NetworkManager/system-connections/Wi-Fi connection 1 (or whatever) and confirm that your WPA password is stored in plain text.

*) Edit ~/.config/openbox/autostart so that the line which starts gnome-keyring is:

export $(gnome-keyring-daemon --start --components=pkcs11,secrets)

(no ampersand at the end)
EDIT It is recommended to move the above line from ~/.config/openbox/autostart to ~/.config/openbox/environment. This way you can add ssh or gpg to the components option, should you want to in the future.

*) Right-click the NM system-tray applet > Edit Connections... > select the WiFi connection > Delete

*) Confirm that /etc/NetworkManager/system-connections/Wi-Fi connection 1 is now empty.

*) Reboot just to be sure everything is flushed out.

*) Go to NM's systray app and setup your WiFi connection again. Make sure that on the "General" tab "All users may connect to this network" is NOT checked, but DO check "Automatically connect to this network when it is available".

*) Log out and back in, confirm that the connection has been made automatically.

*) Check /etc/NetworkManager/system-connections/Wi-Fi connection 1 and confirm that it does not contain the password (though it does have the SSID etc.)

*) Try

sudo grep -r '<mypassword>' /etc

to confirm it hasn't been moved somewhere else. (you could also try /usr or /home when you have some free time...)

...it seems to be working.

Last edited by johnraff (2016-02-12 05:29:15)

johnraff · 2016-02-03 07:38:07

About $GNOME_KEYRING_CONTROL not being set. It seems gnome-keyring no longer exports that variable:
https://mail.gnome.org/archives/commits … 03863.html
So panic over on that one.

About the line:

/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &

I have confirmed that on a fresh BL install, with this line present in openbox/autostart then a click in Thunar to mount a different hard disk partition brings up a password box. If the line is commented out, then you get a "permission denied" box.

xaos52 · 2016-02-03 08:33:31

@John
Your post #33.

Try putting that

export XDG_CURRENT_DESKTOP=XFCE

in autostart in stead of environment.

hhh · 2016-02-03 08:40:40

Nothing of value to add here. Just a fan in awe of the conversation. Cheers!

-edit- ^,^^, I thought we were doing that now already. I could be wrong, this is John's field.

hhh · 2016-02-03 08:46:18

johnraff wrote:

About the line:
/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
I have confirmed that on a fresh BL install, with this line present in openbox/autostart then a click in Thunar to mount a different hard disk partition brings up a password box. If the line is commented out, then you get a "permission denied" box.

We want the former, yes? BTW, that's rc1 or the super-double-secret-probation rc2 preview?

tknomanzr · 2016-02-03 08:47:26

^ This confirms my suspicions on that then. Thanks for the info.

xaos52 · 2016-02-03 09:12:21

Thx, HoaS.
It is a pity that John and I are rarely there at the same time. Otherwise we would be at it all day I think.

#21 2016-01-31 10:11:47

Re: initializing gnome-keyring-daemon in autostart

#22 2016-01-31 10:36:26

Re: initializing gnome-keyring-daemon in autostart

#23 2016-01-31 18:19:35

Re: initializing gnome-keyring-daemon in autostart

#24 2016-01-31 19:51:46

Re: initializing gnome-keyring-daemon in autostart

#25 2016-02-01 03:19:31

Re: initializing gnome-keyring-daemon in autostart

#26 2016-02-01 05:39:42

Re: initializing gnome-keyring-daemon in autostart

#27 2016-02-01 09:06:43

Re: initializing gnome-keyring-daemon in autostart

#28 2016-02-02 04:27:18

Re: initializing gnome-keyring-daemon in autostart

#29 2016-02-02 08:51:05

Re: initializing gnome-keyring-daemon in autostart

#30 2016-02-02 11:04:04

Re: initializing gnome-keyring-daemon in autostart

#31 2016-02-02 19:39:29

Re: initializing gnome-keyring-daemon in autostart

#32 2016-02-03 04:43:45

Re: initializing gnome-keyring-daemon in autostart

#33 2016-02-03 04:54:33

Re: initializing gnome-keyring-daemon in autostart

#34 2016-02-03 07:30:47

Re: initializing gnome-keyring-daemon in autostart

#35 2016-02-03 07:38:07

Re: initializing gnome-keyring-daemon in autostart

#36 2016-02-03 08:33:31

Re: initializing gnome-keyring-daemon in autostart

#37 2016-02-03 08:40:40

Re: initializing gnome-keyring-daemon in autostart

#38 2016-02-03 08:46:18

Re: initializing gnome-keyring-daemon in autostart

#39 2016-02-03 08:47:26

Re: initializing gnome-keyring-daemon in autostart

#40 2016-02-03 09:12:21

Re: initializing gnome-keyring-daemon in autostart

Board footer