Gnome-keyring - unlocked

[fehlix]

...
The dashes in front of auth optional pam_gnome_keyring.so and session optional pam_gnome_keyring.so auto_start inactivates the options, so PAM was never starting the keyring.

I removed the dashes, logged out and in, and now everything works perfectly.

@bwhawk ,
I've just check and verfied the procedure described at the beginning
of this thread and now also within this MX-Wiki entry MX-Wiki: gnome-keyring
by booting from a MX17.1-ISO and just installing libpam-gnome-keyring.

The two lines starting with a dash, you mentioned above,
are still present within /etc/pam.d/lightdm as shown here:

Code: Select all

cat   /etc/pam.d/lightdm  | grep keyring
-auth  optional pam_gnome_keyring.so
-session optional        pam_gnome_keyring.so auto_start

After logout and login I do find within "Password and Keys"
a newly generated login-keyring which was aromatically unlocked
and marked as the default keyring.

To further proof that this login-keyring will be used by an app
requesting credentials I also installed Chromium from MXPI.
Starting Chromium without any password prompt
I can verify that Chromium's internal key was stored within the default/login
gnome-keyring.
So you seem to have done or set up something differently, which
caused some additional steps to do.

[bwhawk]

Yeah, I figured it probably worked normally for most people, or I would have found more incidents of this happening. I was mostly posting this in the hopefully unlikely event anyone else ever experiences it.

Although I am curious. Since the lines are commented out, what is launching gnome-keyring-daemon for you?

[fehlix]

Since the lines are commented out, what is launching gnome-keyring-daemon for you?

Well, the pam-moule is started by pam.
Appears to me that the dash (hyphen) sign is more relevant to system log
related events according to the man page of pam.d:

man pam.d
...

The type is the management group that the rule corresponds to. It is used to specify which of the management
groups the subsequent module is to be associated with. Valid entries are:
...
auth
this module type provides two aspects of authenticating the user. Firstly, it establishes that the user is
who they claim to be, by instructing the application to prompt the user for a password or other means of
identification. Secondly, the module can grant group membership or other privileges through its credential
granting properties.
...
If the type value from the list above is prepended with a - character the PAM library will not log to the
system log if it is not possible to load the module because it is missing in the system. This can be useful
especially for modules which are not always installed on the system and are not required for correct
authentication and authorization of the login session.

[bwhawk]

So that other document is wrong. Which I can believe because after I restarted my system and logged in, the default keyring wasn't unlocked. In my previous test, I only logged out and back in, and that doesn't seem to be enough of a test, at least for my system.

So I'm back where I started from. I'll keep trying to track this down.

[fehlix]

...I restarted my system and logged in, the default keyring wasn't unlocked. In my previous test, I only logged out and back in, and that doesn't seem to be enough of a test, at least for my system.

To be precise: Pam will unlock the login-keyring after login. If you have only one keyring the login-keyring becomes also the "default keyring". If you have more than one keyring it will further unlock the other keyring on app-request. I.e. after login the other keyring appears to be locked, but will be unlocked automatically by PAM if an application requires access. You can choose another keyring as the default keyring and instruct PAM to unlock the other keyring on application request, as described within my first post of this thread. If an app does not specify which keyring to access the "default keyring" will used.

[bwhawk]

The problem is that PAM isn't unlocking the login keyring when I login. So that's what I'm trying to track down. Perhaps I'm missing some PAM components or something is weird in one of the config files.

[fehlix]

The problem is that PAM isn't unlocking the login keyring when I login.

Simple solution: Remove the login keyring using "Password and keys", logout and login. PAM will create a new login keyring, and will also make sure, that the login-keyring will synced any account password changes. In the old days you would need to manually adjust the login keyring-password, after having changed your user account login-password. The newer pam will take care to synchronise both.
Manual solution: Make sure you login-keyring password is identical to you login-account password.

Note further: PAM wil only unlock login-keyring if you authenticate with your password during login. With auto-login PAM cannot unlock the login-keyring as no credentials have been provided.

[bwhawk]

Yes, I've tried that several times.

Just now, I deleted the entire ~/.local/share/keyrings folder. When I restarted and logged back in, the folder was not created. That's why I think PAM isn't running, or at least isn't running correctly.

[fehlix]

Yes, I've tried that several times.

Just now, I deleted the entire ~/.local/share/keyrings folder. When I restarted and logged back in, the folder was not created. That's why I think PAM isn't running, or at least isn't running correctly.

Hmm you can verify how it supposed to be by running from a LiveUSB/ISO. just installation of libpam-gnome-keyring logout and login as normal user demo, would do. Not sure what's differenf within your setup.

[bwhawk]

I'm about to build a new system anyway, which will hopefully render this whole problem moot since I'll be installing a fresh copy of MX 17.1. I just hate admitting defeat.