SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
sufficient
[success=done new_authtok_reqd=done default=ignore]
done
equivalent to ok with the side effect of terminating the module stack
and PAM immediately returning to the application
substack
This differs from include in that evaluation of the done and die
actions in a substack does not cause skipping the rest of the complete
module stack, but only of the substack.
This means that system-auth has to be substack-ed and not included if it is not the last in the stack.
The stack wont reach pam_gnome_keyring.so. I wonder why this module is here. Why checking my mail should open gnome keyring.
The auth group is the suggested place by the man page for pam_nologin.so (in the account group one most likely wont see the nologin message).
Also some services like screensavers wont use the account group. But for some services like atd it has to be in the account group.
So system-auth is not the best place for pam_nologin.so.
Overall I think that system-auth should include only the authentication method specific modules (pam_unix.so or pam_winbind or pam_krb5 ...).
I was trying to use the gnome-keyring auto unlocking feature which doesn't work with the default pam configuration shipped by testing/PAM. Then, just like ivandi, I found out that pam_gnome_keyring.so module was listed after pam_unix.so with sufficient as its control type. The same system-auth configuration file also has
which will automatically start gnome-keyring-daemon in the background. But, because pam_gnome_keyring.so is not loaded at authentication phase (just like what ivandi said), the default "login" keyring is still locked thus I have to enter the keyring password manually.
So, assuming that we want the full gnome-keyring and PAM integration, I suggest two alternatives:
1. Change the sufficient control type of relevant pam_unix.so with [success=1 default=ignore] and change pam_deny.so control type to [default=die], that way if pam_unix.so returns success, pam_deny.so will be skipped and pam_gnome_keyring.so will be loaded (and thus unlocking the "login" keyring). Else, it will load pam_deny.so and return immediately with PAM_AUTH_ERR as its return value. Also, add "password optional pam_gnome_keyring.so" to system-auth, which will make gnome-keyring automatically change the "login" keyring password to match the user's new password if the user decides to change his/her password.
Code:
--- system-auth 2020-02-11 05:54:26.000000000 +0700
+++ system-auth.new 2020-02-17 02:05:49.888109565 +0700
@@ -14,8 +14,8 @@
auth required pam_env.so
auth required pam_tally2.so
#
-auth sufficient pam_unix.so likeauth nullok
-auth required pam_deny.so
+auth [success=1 default=ignore] pam_unix.so likeauth nullok
+auth [default=done] pam_deny.so
auth optional pam_gnome_keyring.so
##################
@@ -52,14 +52,15 @@
# password quality checking, comment out these two lines and uncomment the
# traditional password handling line below.
password requisite pam_pwquality.so minlen=6 retry=3
-password sufficient pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok
+password [success=1 default=ignore] pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok
# Traditional password handling without pam_pwquality password checking.
# Commented out by default to use the two pam_pwquality lines above.
#password sufficient pam_unix.so nullok sha512 shadow minlen=6
# ATTENTION: always keep this line for pam_deny.so:
-password required pam_deny.so
+password [default=done] pam_deny.so
+password optional pam_gnome_keyring.so
#########################
# Session Configuration #
2. Just like the first alternative but instead of putting pam_gnome_keyring.so in system-auth, put it somewhere else. For example, I think "auth optional pam_gnome_keyring.so" and "session optional pam_gnome_keyring.so auto_start" are better to be put inside /etc/pam.d/login and other login methods' PAM config files like /etc/pam.d/sddm. As for "password optional pam_gnome_keyring.so", it can be put inside /etc/pam.d/passwd (as suggested by the GNOME wiki: https://wiki.gnome.org/Projects/GnomeKeyring/Pam). The advantage of this approach is that pam_gnome_keyring.so will only be loaded when it's needed (i.e. when first logging in to the system, which is probably the only time it's needed) and thus avoiding what ivandi had said. Of course this will mean additional PAM config files need to be maintained instead of just using the "<type> include system-auth" entries.
Cheers
Last edited by mumahendras3; 02-16-2020 at 02:35 PM.
Reason: Wrong [CODE] closing tag
For those of us who don't do much in the way of security (simple passwords for root and user), everything outside firewalled off, etc..
What practical impact will PAM have? Will it force me to assign a good password? I've used a based root password for 20+ years and I want to keep using it - the muscle memory is VERY strong :-) And every new installation, Slackware complains "password is weak, enter again to use anyway" and I do.
Do I have to disable PAM somehow? Or will it continue this behavior?
Distribution: slack 7.1 till latest and -current, LFS
Posts: 366
Rep:
Quote:
Originally Posted by slackerDude
For those of us who don't do much in the way of security (simple passwords for root and user), everything outside firewalled off, etc..
What practical impact will PAM have? Will it force me to assign a good password? I've used a based root password for 20+ years and I want to keep using it - the muscle memory is VERY strong :-) And every new installation, Slackware complains "password is weak, enter again to use anyway" and I do.
Do I have to disable PAM somehow? Or will it continue this behavior?
the behavior should be the same. so nothing should change on that part.
For those of us who don't do much in the way of security (simple passwords for root and user), everything outside firewalled off, etc..
What practical impact will PAM have? Will it force me to assign a good password? I've used a based root password for 20+ years and I want to keep using it - the muscle memory is VERY strong :-) And every new installation, Slackware complains "password is weak, enter again to use anyway" and I do.
Do I have to disable PAM somehow? Or will it continue this behavior?
The default behaviour for PAM-ified Slackware is to force good password (at least for now). You can still revert back to the old behaviour by modifying /etc/pam.d/system-auth
Code:
#############################
# Password quality checking #
#############################
#
# Please note that unless cracklib and libpwquality are installed, setting
# passwords will not work unless the lines for the pam_pwquality module are
# commented out and the line for the traditional no-quality-check password
# changing is uncommented.
#
# The pam_pwquality module will check the quality of a user-supplied password
# against the dictionary installed for cracklib. Other tests are (or may be)
# done as well - see: man pam_pwquality
#
# Default password quality checking with pam_pwquality. If you don't want
# password quality checking, comment out these two lines and uncomment the
# traditional password handling line below.
password requisite pam_pwquality.so minlen=6 retry=3
password [success=1 default=ignore] pam_unix.so nullok sha512 shadow minlen=6 try_first_pass use_authtok
# Traditional password handling without pam_pwquality password checking.
# Commented out by default to use the two pam_pwquality lines above.
#password sufficient pam_unix.so nullok sha512 shadow minlen=6
What practical impact will PAM have? Will it force me to assign a good password? I've used a based root password for 20+ years and I want to keep using it - the muscle memory is VERY strong :-) And every new installation, Slackware complains "password is weak, enter again to use anyway" and I do.
PAM will warn you if it thinks the password is weak, but root will be allowed to set it anyway.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
