initializing gnome-keyring-daemon in autostart

hhh · 2016-02-03 09:23:05

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.

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.

xaos52 · 2016-02-03 10:07:19

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

iMBeCil · 2016-02-03 13:46:31

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.

xaos52 · 2016-02-03 14:18:58

^ 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?

iMBeCil · 2016-02-03 15:13:56

^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 :8 )

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)

xaos52 · 2016-02-03 17:27:52

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.

xaos52 · 2016-02-03 17:48:34

@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**

johnraff · 2016-02-04 05:14:50

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)

johnraff · 2016-02-04 05:19:33

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.

johnraff · 2016-02-04 05:29:59

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.

xaos52 · 2016-02-04 07:07:29

^agreed

hhh · 2016-02-04 07:13:08

Damn. You gents are on it.

xaos52 · 2016-02-04 07:17:06

@hhh
We are just brainstorming here.
We actually respect each other, I think. Well I do.
The goal is to enlighten each other and eventually reach agreement.

hhh · 2016-02-04 07:31:23

xaos52 wrote:

We are just brainstorming here.

Yes. You, johnraff, damo, HoaS, nobody, Sector11, Unia, pvsage, tknomanzr (how the eff do you spell that?), bronto-rex, fog, ohnonot... I think BL will be OK for a while.

xaos52 · 2016-02-04 07:59:21

@John

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.

Does not work for me.
The variable is not set.

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

Am doing all my testing now in the first RC2 that hhh provided (not the last one - but I don't think it makes a difference) updated and upgraded.

Just tested again to be really sure. Same result.

me@medion:~/tmp/today$ acp openbox
openbox:
  Installed: 3.5.2-8
  Candidate: 3.5.2-8
  Version table:
 *** 3.5.2-8 0
        500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

johnraff · 2016-02-04 08:14:34

xaos52 wrote:

We actually respect each other, I think.

Of course!!
And I learn a lot from these discourses.
Eventally, we come to an agreement and things move on...

johnraff · 2016-02-04 08:21:39

xaos52 wrote:

@John
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.
Does not work for me.
The variable is not set.

I just did another test, and sure enough the variable was set!
But... that was on a VirtualBox VM, and that was already suspected of being the cause of some strange behaviour with $SSH_AUTH_SOCK

I tried another test, on a real machine this time, not a VM, and...

...the variable was NOT set.

So, OK we've established two things:

openbox/autostart can no longer be used (as it was by many people in the past) for exporting environment variables. That is perhaps why the file openbox/environment was added.
VirtualBox VMs cannot be trusted with environment variables.

xaos52 · 2016-02-04 08:58:05

I am now experimenting with moving the gnome-keyring-daemon --start thing to $HOME/.config/openbox/environment and first results are promising.

This seems to do the trick:

## GNOME Keyring
# WARNING: interpreter is dash!
while read -r _line
do
    _var=${_line%=*}
    _value=${_line#*=}
    eval if [ -z \$"$_var" ]\; then export "$_var"="$_value"\; fi
done <<EOF
$(gnome-keyring-daemon --start --components=pkcs11,secrets,ssh,gpg)
EOF
unset _line _var _value

Had to resort to
1. using eval.
It is safe here because only using output from gnome-keyring-daemon.
2. Here-doc because the exports can not be done in a subshell. That would prevent the variables to be set in the openbox environment.

Testing if any of the variables was set already, which will be the case if either ssh-agent and/or gpg-agent are present on the system. If they are, their settings have priority over the gnome-keyring-daemon settings.

I have already tested the case where ssh is installed, but ssh-agent is disabled and gnupg-agent is not installed:

me@medion:~$ env| grep -iE 'ssh|gpg'
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

Need to test scenarios where:
1. stand-alone ssh-agent is enabled.

me@medion:~$ env| grep -iE 'ssh|gpg'
SSH_AGENT_PID=7169
GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
SSH_AUTH_SOCK=/tmp/ssh-xNQ7yA6vkgtG/agent.7145
me@medion:~$

2. stand-alone gpg-agent is installed and enabled.

me@medion:~$ env| grep -iE 'ssh|gpg'
SSH_AGENT_PID=8058
GPG_AGENT_INFO=/tmp/gpg-nDsiNK/S.gpg-agent:8059:1
SSH_AUTH_SOCK=/tmp/ssh-kTbKHjVDuDDq/agent.8033
me@medion:~$

Seems to work in all cases.

xaos52 · 2016-02-04 09:01:10

And I learn a lot from these discourses.

Me too, John, me too.

johnraff · 2016-02-05 03:18:41

About the XDG_CURRENT_DESKTOP discussion, this is a different topic, and a thread already exists for it: https://forums.bunsenlabs.org/viewtopic.php?id=1116

It's also important, but I hope no-one minds if I move the posts referring only to that topic over there, so we can focus on gnome-keyring here.

(If anyone objects, I can move the posts back here again.)

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

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

Re: initializing gnome-keyring-daemon in autostart

#51 2016-02-04 07:07:29

Re: initializing gnome-keyring-daemon in autostart

#52 2016-02-04 07:13:08

Re: initializing gnome-keyring-daemon in autostart

#53 2016-02-04 07:17:06

Re: initializing gnome-keyring-daemon in autostart

#54 2016-02-04 07:31:23

Re: initializing gnome-keyring-daemon in autostart

#55 2016-02-04 07:59:21

Re: initializing gnome-keyring-daemon in autostart

#56 2016-02-04 08:14:34

Re: initializing gnome-keyring-daemon in autostart

#57 2016-02-04 08:21:39

Re: initializing gnome-keyring-daemon in autostart

#58 2016-02-04 08:58:05

Re: initializing gnome-keyring-daemon in autostart

#59 2016-02-04 09:01:10

Re: initializing gnome-keyring-daemon in autostart

#60 2016-02-05 03:18:41

Re: initializing gnome-keyring-daemon in autostart

Board footer