PAM about to be merged in -current

gegechris99 · 06-15-2020, 01:48 PM

Quote:

Originally Posted by kevmccor

So, what is the Slackware method or what do we do to have gnome-keyring working properly with password access?

I don't use gnome-keyring but based on my understanding of Slackware PAM configuration files and this Gnome Keyring documentation, you get the following process out of the box.

Slackware PAM configuration file will automatically launch gnome-keyring when you log in using either the console, xdm or kdm.
It will open your 'login' keyring using your user password.

Prerequisite: you must use the 'login" keyring and make its password the same as your user password.

If you are using a display manager not provided by Slackware (ex: gdm, lxml), you should make sure it is compiled with PAM support (if it's possible at all). The PAM-enabled display manager should have its own configuration file in /etc/pam.d that will most probably need to be tweaked.

pyllyukko · 06-15-2020, 03:12 PM

Hi.

What's the point in the following lines in /etc/pam.d/system-auth:

Code:

auth        sufficient    pam_unix.so likeauth nullok
auth        required      pam_deny.so
-auth        optional      pam_gnome_keyring.so

The pam_gnome_keyring.so never gets executed with successful login because of the sufficient in pam_unix.so.

EDIT: Apparently this was already brought up by Gazl in this comment.

gegechris99 · 06-17-2020, 01:27 AM

This has now been corrected in current.

Other comments posted by GazL are also being considered.

Quote:

Tue Jun 16 20:50:41 UTC 2020
a/shadow-4.8.1-x86_64-10.txz: Rebuilt.
system-auth: auth required pam_unix.so [...], otherwise the stack exits
before pam_gnome_keyring.so executes. Thanks to pyllyukko.
Get rid of "auth required pam_deny.so" which seems like a mistake.
Still pending: consider GazL's comments on moving stuff out of system-auth.

kevmccor · 06-17-2020, 08:46 AM

This documentation of gnome keyring states that the login keyring is created automatically. In my case the "login" keyring was not auto-magically created, leading to google-chrome creating its own keyring as the default. I used sbopkg to install seahorse and seahorse-plugins, which is called "Passwords and Keys" in the XFCE | system menu, and then added the login key with my login password. Whether this accomplished anything is at present unknown, but I have no trouble logging in or using XFCE. I was using Fluxbox and then switched to XFCE for my window manager and have tried to use non-kde applications with XFCE. Most Slackware users would probably have similar issues with the kde kwallet application.

For me, the concern is not the technical details of how Slackware implements pam, but the information describing the basics for the user. After spending a couple of hours reading about pam and gnome keyring, my conclusion is that security through obscurity is alive and well. One must realize that combinations of arrangements quickly become quite complicated. I think gnome-keyring is an encrypted data file similar to keepassx (which I have used for years), but it is tied into the background process, so if it fails there is no obvious context or explanation for the user. IMHO, a mysterious password security system is not really very helpful, so the main point is to prevent it from being a frustrating problem for users.

arfon · 06-17-2020, 09:15 AM

Quote:

Apparently the best way is: ignore it and it will not bother you.

THAT has been the secret to my happy life.

pyllyukko · 04-17-2021, 04:30 PM

Another question... What is the purpose of this pam_succeed_if line in system-auth:

Code:

account     sufficient    pam_succeed_if.so uid < 100 quiet
account     required      pam_permit.so

It's completely redundant, as the next line will also grant access. Also I'm interested what should be special about UID < 100 and what has been the intent here.

pyllyukko · 04-18-2021, 05:10 AM

I noticed that /etc/pam.d/sudo is missing from the sudo package. This means that when using sudo it will use /etc/pam.d/other, which is not good IMO. I have populated my /etc/pam.d/other with pam_deny.so so that unidentified programs don't get to authenticate with PAM (or in other words the default policy is to deny).

Edit: /etc/pam.d/sshd has "auth include postlogin" which does not make sense. Postlogin refers to stuff happening after authentication and the file itself contains only session lines.