Page 2 of 2

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 01 Aug 2019 20:47
by Arjen Balfoort
I'm sorry, but that ISO is already gone.
You can, however, create the file on a clean install and get the same result:

Code: Select all

mkdir ~/.local/share/keyrings
echo 'login' > ~/.local/share/keyrings/default
apt install chromium
chromium

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 02 Aug 2019 15:58
by ilu
I've already done that.

- Manually creating the file after install works. You just have to reboot before opening chromium.

- Manually adding the skel directory and default file and creating a new user, reboot, open chromium also works. As long as lightdm doesn't forget to open the login.keyring (which it sometimes does upon relog, thus reboot in between).

- The only thing I haven't tested is whether it works for the first user upon install.
Arjen Balfoort wrote:
01 Aug 2019 07:31
I booted the live ISO and verified that only ~/.local/share/keyrings/default existed and had "login" as contents.
...
I verified that only ~/.local/share/keyrings/default existed and had "login" as contents.
That's the problem. After reboot and login pam and lightdm should have created the login.keyring. This keyring has to be there and open for chromium to use. And upon creating a new user this works. Why not for the first user?

Anyway, I agree with grizzler that no password is a no-go. Adding the default file in /skel doesn't make things worse if it just gets overwritten but has the chance to make things better if pam/lightdm feel like it. (note to self: https://bugs.launchpad.net/ubuntu/+sour ... ug/1689825) Also it makes it easier for us to help users who encounter the problem - just tell them

Code: Select all

sudo cp /etc/skel/.local/share/keyrings/default ~/.local/share/keyrings/default
sudo chown user:users  ~/.local/share/keyrings/default
So I'd say, add the directory with that one file to /skel.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 02 Aug 2019 16:40
by Arjen Balfoort
ilu wrote:
02 Aug 2019 15:58
So I'd say, add the directory with that one file to /skel.
@Grizzler?

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 03 Aug 2019 05:30
by grizzler
Agreed. The 'default' file isn't in the way.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 12 Sep 2019 11:04
by ilu
On my SolydX9 system the login.keyring is used by chromium 100%, so that works. But about 3/4 of the time the login.keyring doesn't get unlocked upon login. There is still something wrong in between PAM and lightdm. I worked through
https://wiki.gnome.org/Projects/GnomeKe ... AM_Support
https://wiki.gnome.org/Projects/GnomeKeyring/Pam/Manual
and it looks like everything is configured correctly in /etc/pam.d. Except that the gnome doc expects the keyring to be in $HOME/.gnome2/keyrings/login.keyring but I don't think that matters.

Edit: And except the setting In /etc/pam.d/gnome-screensaver. Actually testing this now and I'm almost sure it's the screensaver or the unlock after screensaving, whichever does that. Immediately after restart everything works, login/logout also opens the keyring. Maybe light-locker needs its own pam conf file. Further testing ... grr the stupid thing doesn't lock if you stare at the screen. :evil:

But we also have files with the same names in /usr/share/pam which don't have the correct configs. Usually /usr/share entries should take precedence, right? But I can't find anything about a directory named /usr/share/pam. Why does it exist? Is it even read? Not according to pam.d(5), so wrong track.

And there is a gnome-keyring file in /usr/share/pam-configs/ which is probably shipped with gnome-keyring but not mentioned in the gnome docs.

Finally I'm able to reproduce the issue. login.keyring doesn't get unlocked after light-locker has kicked in .... but not always :roll:

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 12 Sep 2019 22:53
by ilu
I checked and on a fresh install there is no login.keyring file. Lightdm/pam/gnome-keyring do not create that file and as a consequence nothing is ever unlocked on login. At least I solved that part of the problem:

The terminal way of creating a login.keyring file is:

Code: Select all

~$ gnome-keyring-daemon --unlock
UserLoginPassword
ctrl-D
The daemon takes the login password and creates the keyring. This is obviously not meant to be run in terminal but meant to be called by another program - the installer comes to mind. @Arjen do you think that command could be incorporated in the installer? That would at least leave new installed system with a - in most cases - working keyring config (except in those cases where it is randomly not working ...).

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 16 Sep 2019 17:18
by wildman
I'm not sure if this has been mentioned but the addition of a command parameter to the menu entry or launcher will fix the problem. It tells chromium to not use the keyring.

Code: Select all

/usr/bin/chromium %U --password-store=basic

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 16 Sep 2019 18:28
by grizzler
And makes it store the passwords in plain text. Not what we're after...

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 16 Sep 2019 19:36
by wildman
grizzler wrote:
16 Sep 2019 18:28
And makes it store the passwords in plain text. Not what we're after...
OK, I didn't consider that.
"Never mind.", Emily Litella. :)

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 17 Sep 2019 10:53
by Arjen Balfoort
ilu wrote:
12 Sep 2019 22:53
@Arjen do you think that command could be incorporated in the installer? That would at least leave new installed system with a - in most cases - working keyring config (except in those cases where it is randomly not working ...).
I'm afraid not. The installer runs as root and gnome-keyring-daemon needs to be run as user. It also needs a user home directory which doesn't exist until the user logs in the first time. I could try to create a script that does that on first login. I'll investigate that but that won't help existing users.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 17 Sep 2019 11:56
by ilu
There is not much we can do for existing users. I'm trying to find a good solution for the new ISO release. pam/lightdm should create the keyring upon first login but it obviously doesn't. Documentation is bad. I'm probably going to open an issue with canonical but no idea whether anything comes from it ... they seem to play the blame game (let the other component do it).
Edit: https://github.com/canonical/lightdm/issues/89

So some script that gets called on first login would be good.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 17 Sep 2019 12:20
by Arjen Balfoort
A ~/.config/autostart/create-keyring.desktop file should do it:

Code: Select all

[Desktop Entry]
Exec=sh -c "echo \"NEW_USER_PWD\" | gnome-keyring-daemon --unlock; rm /etc/xdg/autostart/create-keyring.desktop"
StartupNotify=false
Terminal=false
Type=Application
Name=Create Login Keyring
There are some problems, however. The desktop file cannot be placed in /etc/skel or /etc/xdg, only in the user home directory, but the home directory doesn't exist until first login. Not to mention that NEW_USER_PWD is plain text and thus not safe. I could leave NEW_USER_PWD empty. That would be a generic solution for all users on the system if I place the desktop file in /etc/xdg/autostart.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 17 Sep 2019 16:32
by ilu
I'm not exactly sure what this desktop file does but couldn't it start a script including a window with a prompt like "Enter your user password to setup the keyring" ?

I really wonder how other distros do this ... somehow we are missing the right solution.

---------------

As for the second problem (login.keyring randomly not opened) : I'm seeing " gnome-keyring-daemon[2983]: asked to register item /org/freedesktop/secrets/collection/login/4, but it's already registered" in /var/log/auth.log. It seems to be this issue https://gitlab.gnome.org/GNOME/gnome-keyring/issues/24 and this one https://gitlab.gnome.org/GNOME/gnome-keyring/issues/37. Nothing much happened about it.

I also found this bug report: https://bugs.launchpad.net/ubuntu/+sour ... ug/1022322 from 2012 which says the culprit is the missing "XFCE" in "OnlyShowIn=GNOME;Unity;" in /etc/xdg/autostart/gnome-keyring-pkcs11 (which is part of the keyring package). XFCE is still missing there. I added it and am testing now ...

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 17 Sep 2019 17:28
by Arjen Balfoort
That would be a complicated solution for something that simple. It would also confuse the user.

I'd like to investigate the other distros but unfortunately my PC broke down today and I am low on cash to buy a new one. I'm now posting this with my mobile.

All changes, including the ISOs will have to wait, I'm afraid.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 19 Sep 2019 08:53
by Arjen Balfoort
Do you know of a distribution that has a properly working gnome-keyring?

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 19 Sep 2019 14:28
by Arjen Balfoort
I have added XFCE to /etc/xdg/autostart/gnome-keyring-pkcs11 and built a new SolydX-10 ISO.

That didn't change anything in the live session but to my surprise it worked after installing!

Screenshot_20190919_144722.png
Screenshot_20190919_144722.png (19.84 KiB) Viewed 600 times

I could lock and unlock with my own password.

I haven't tested with Chromium, yet.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 20 Sep 2019 16:08
by ilu
Great. I'll test install the new ISO on the weekend.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 20 Sep 2019 20:36
by Arjen Balfoort
I just finished uploading the fixed ISOs.

Re: Gnome-keyring problems (with chromium) [partly solved]

Posted: 06 Nov 2019 14:44
by ilu
On SolydXK 10 this is now working perfectly for me. I'm declaring this solved, yay us! :lol: