You are not logged in.

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

hhh
Meep!
Registered: 2015-09-17
Posts: 9,613
Website

Re: initializing gnome-keyring-daemon in autostart

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

Online

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

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

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.

Offline

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

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

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.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

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

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: initializing gnome-keyring-daemon in autostart

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.

Offline

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

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

*)   /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.

Offline

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

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

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

Offline

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

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

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.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

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

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

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!


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

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

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

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. smile

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


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

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

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

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.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

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

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

@John
Your post #33.

Try putting that

export XDG_CURRENT_DESKTOP=XFCE

in autostart in stead of environment.

Offline

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

hhh
Meep!
Registered: 2015-09-17
Posts: 9,613
Website

Re: initializing gnome-keyring-daemon in autostart

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.

Online

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

hhh
Meep!
Registered: 2015-09-17
Posts: 9,613
Website

Re: initializing gnome-keyring-daemon in autostart

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?

Online

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

tknomanzr
BL Die Hard
From: Around the Bend
Registered: 2015-09-29
Posts: 1,029

Re: initializing gnome-keyring-daemon in autostart

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

Offline

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

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

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. smile

Offline

#41 2016-02-03 09:23:05

hhh
Meep!
Registered: 2015-09-17
Posts: 9,613
Website

Re: initializing gnome-keyring-daemon in autostart

xaos52 wrote:

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. smile

Without a doubt.. leave out the Open-Source software and the #! passion and everything else... the coolest thing for me has been the forums and the international thing we have going.

Online

#42 2016-02-03 10:07:19

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

@John,
OK, thx for clarifying this.

The point I was trying to make - and failed because of the typo - is that in the autostart file you can just as well replace

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

by

gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg

because the variables that are output by that command are not exported to the openbox environment.

So if we want gnome-keyring to work no matter if ssh or gpg is installed, we will have to find a place other than autostart to start the gnome-keyring components and set the correct environment variables.
Perhaps I spoke too soon here. Remains to be tested.

Offline

#43 2016-02-03 13:46:31

iMBeCil
WAAAT?
From: Edrychwch o'ch cwmpas
Registered: 2015-09-29
Posts: 767

Re: initializing gnome-keyring-daemon in autostart

DISCLAIMER: I'm sorry if this post is going to add to the confusion about gnome-keyring or if this is gonna be entirely useless. Moreover, it might be outdated ...

A while ago, I started to use (vanilla) #! with Slim + OpenBox. Then I decided to change default #! a bit: to remove DM (Slim), use 'startx' and use PekWM instead of OpenBox.

To make it work, I had to do:
1) add usual 'startx', but in $HOME/.profile (!), not in $HOME/.bashrc, otherwise gnome-keyring didn't work
2) edit PAM (almost by trial and error) so it looked like (order was important):

$ cat /etc/pam.d/login
auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

# by imbecil
auth    required        pam_env.so readenv=1
auth    required        pam_env.so readenv=1 envfile=/etc/default/locale

@include common-auth
auth       optional   pam_group.so

# by imbecil
# see https://wiki.archlinux.org/index.php/GNOME_Keyring
auth       optional     pam_gnome_keyring.so

session    required   pam_limits.so

# by imbecil
# added differences compared to /etc/pam.d/slim
session    required     pam_loginuid.so

session    optional   pam_lastlog.so
session    optional   pam_motd.so  motd=/run/motd.dynamic
session    optional   pam_motd.so
session    optional   pam_mail.so standard
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
@include common-account
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
@include common-password

# by imbecil
# see https://wiki.archlinux.org/index.php/GNOME_Keyring
session    optional     pam_gnome_keyring.so        auto_start

3) PekWM runs an autostart file; however, I didn't have to put 'gnome-keyring-daemon' nor anything similar inside; it seemed that starting the gnome-keyring was result of /etc/pam.d/login configuration file (see above)

I hope this can add some light to the gnome-keyring ... It was long time ago, I don't really remember all of the details.


Postpone all your duties; if you die, you won't have to do them ..

Offline

#44 2016-02-03 14:18:58

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

^ Yes, that could be sufficient for 'normal keyring usage'.
What we are discussing here is making sure everything works for all possible cases, mixing all combinations of ssh, no ssh, gpg, no gpg, pkcs11 usage.

e.g. what if a user uses ssh, no ssh-agent because he wants keyring to handle that. Does our setup still work?

Offline

#45 2016-02-03 15:13:56

iMBeCil
WAAAT?
From: Edrychwch o'ch cwmpas
Registered: 2015-09-29
Posts: 767

Re: initializing gnome-keyring-daemon in autostart

^Oh, I see. Thanks for clarifying this to me.

I'm afraid I can't be of much help for all that ... no real experience. (Although, I wonder why mix everything ... but perhaps I didn't read entire topic careful enough ops )

xaos52 wrote:

e.g. what if a user uses ssh, no ssh-agent because he wants keyring to handle that. Does our setup still work?

AFAICR, gnome-keyring-daemon within my setup did handle (read: unlocked) my 'private ssh keys prepared with non-empty passwords' ...

Last edited by iMBeCil (2016-02-03 15:19:31)


Postpone all your duties; if you die, you won't have to do them ..

Offline

#46 2016-02-03 17:27:52

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

Here is the promised method to enable iceweasel to store and retrieve passwords using gnome-keyring.

Normally iceweasel stores passwords in a database in your profile.
So we need something to switch that behaviour to using the keyring.
That 'something' is ... surprise, surprise an add-on.

clone this repo from github into a directory of your choice
cd into the directory mozilla-gnome-keyring
run the command

make

this will create a file 'gnome-keyring-integration.xpi' in the bin subdirectory.
Thats the iceweasel add-on.

WARNING:
Before you install the add-on you should realize that it switches the normal iceweasel behaviour.
All passwords present in the iceweasel database will become unreachable.
You can make them reachable again by uninstalling the add-on.

To install the add-on point your browser to the xpi file:
(Enter file:///....your path to the cloned git repo ..../mozilla-gnome-keyring/bin/gnome-keyring-integration.xpi)
Let iceweasel install the add-on and restart iceweasel.

From now on new passwords will be stored in the keyring or retrieved from the keyring.

You can verify keys are present in the different keyrings by installing seahorse.

If you want to inspect the keyring from the command line, I can recommend a small python utility 'gkeyring' from this repo.

Here is the output from the command 'gkeyring -all' on my system:

me@medion:~/tmp/today$ gkeyring --all
2	https://www.facebook.com	bvksnvfjhkc
4	https://forums.bunsenlabs.org	dfhgjflktl

The shown passwords are fake, of course. smile

Offline

#47 2016-02-03 17:48:34

xaos52
The Good Doctor
From: Planet of the @pes
Registered: 2015-09-30
Posts: 695

Re: initializing gnome-keyring-daemon in autostart

@John

Confirming that your method for storing the Wi-Fi WPA password in the keyring works.

me@medion:~/tmp/today$ gkeyring --all
2	https://www.facebook.com	**sanitized**
4	https://forums.bunsenlabs.org	**sanitized**
5	Network secret for Wi-Fi connection 1/802-11-wireless-security/psk	**sanitized**

Offline

#48 2016-02-04 05:14:50

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

xaos52 wrote:

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.

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 understand what you're saying here, and looking at /usr/lib/i386-linux-gnu/openbox-autostart (which is launched from /usr/bin/openbox-session) we see:

AUTOSTART="${XDG_CONFIG_HOME:-"$HOME/.config"}/openbox/autostart"
# Run the user openbox autostart script
if test -f $AUTOSTART; then
    sh $AUTOSTART
elif test -f $AUTOSTART.sh; then
    sh $AUTOSTART.sh
fi

which shows that openbox/autostart is launched as a child process. Variables launched from there should not be exportable to the parent shell of course.

BUT...
my openbox/autostart contains:

export TEST_VAR=string

and after a logout/in, in a terminal:

john@bunsen:~$ echo $TEST_VAR
string
john@bunsen:~$ 

So what's happening here? I'm pretty sure it used to be possible to export variables from autostart, but at one time the file was sourced by openbox's startup, not run as a child.

Could it be that you're using a newer version of openbox than what comes with Debian Jessie, with different behaviour? Anyway, could you try that test again? I know exporting shouldn't work - but it seems to anyway...

EDIT: but anyway openbox/environment does work, for sure.

Last edited by johnraff (2016-02-04 05:16:13)


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#49 2016-02-04 05:19:33

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

hhh wrote:
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?

The former, yes. (ie password box) And that's what we have at the moment. I think my test was on RC1 (dist-upgraded) but there's no reason why RC2 should be different in this.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

#50 2016-02-04 05:29:59

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 6,799
Website

Re: initializing gnome-keyring-daemon in autostart

About leaving ssh and gpg out of the gnome-keyring initialization line: it was because of the Debian bug report which said gnome-keyring failed to support some aspects of both of those that ssh-agent and gpg-agent did better. We already supply ssh-agent with openssh-client and gpg-agent is easily installed, so I thought it might be better to follow Debian's example (coming up, or already in Sid) and omit them from gnome-keyring's startup. (It's the equivalent of doing this.) They're easily added back to openbox/autostart if a user prefers to use gnome-keyring.


...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )

Introduction to the Bunsenlabs Lithium Desktop

Offline

Board footer

Powered by FluxBB