PAM about to be merged in -current

That was pre-PAM though. Now we have pam_ck_connector doing the ck-session registration it shouldn't be necessary for xdm to do it itself. Or am I misunderstanding?

I think the first step to fixing this is a
cd /etc/X11/xinit && sed -i 's/DESKTOP_SESSION/XDG_SESSION_COOKIE/' xinitrc.*

And then, adding unset XDG_SESSION_COOKIE to the top of /usr/bin/startx so that it doesn't try and use the ck-session of the tty it's started from.

I think that would restore the status-quo and then we can think about whether it's better to move the ck-session-launch stuff into startx itself, or not.

I'm still not entirely clear on whether a startx -- :2 vt2 executed on tty2 should start a new session or use the existing one (the existing one won't have the x11-display value however, so that looks problematic if one doesn't start a new session. Before PAM, tty logins didn't have a ck-session.

Hello,

Originally Posted by GazL That was pre-PAM though. Now we have pam_ck_connector doing the ck-session registration it shouldn't be necessary for xdm to do it itself. Or am I misunderstanding?

No, no. You're right, and thus the patch xdm-consolekit.patch.gz can be removed.

--
SeB

Just a side node. when I just launch

exec dbus-launch --exit-with-session

like Eric has suggestet,

dbus-send --system --print-reply --dest=org.freedesktop.ConsoleKit /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart

does not work anymore, even though consolekit helper for gvfs seems to work, at least I can access network shares from thunar.

Hi folks,

What can I do now in order to not use PAM at all while staying on the 32-bit current branch as always ?
I use it on standalone machines, no enterprise environment is involved.
I also use LUKS/LVM on my SSD.

Originally Posted by brodo Hi folks, What can I do now in order to not use PAM at all while staying on the 32-bit current branch as always ? I use it on standalone machines, no enterprise environment is involved. I also use LUKS/LVM on my SSD.

PAM has nothing to do with enterprise involvement.
PAM is now part of Slackware-current so if you are running that, you'll have to install it.
What do you think you'll achieve by excluding PAM? What do you think PAM *is* ?

Well, I've read the en.wikipedia.org/wiki/Linux_PAM so generally I know what it does.
I just want to avoid problems when I upgrade my machine to the latest 32 bit current version.
Now I have a current dated 6th of May.

Originally Posted by brodo Well, I've read the en.wikipedia.org/wiki/Linux_PAM so generally I know what it does. I just want to avoid problems when I upgrade my machine to the latest 32 bit current version. Now I have a current dated 6th of May.

If you want to avoid problems while upgrading your boxes, assuming that you did full installations (which is anyways recommended by many) then you should avoid to touch the config files from /etc/pam.d at any costs. PAM will not be in your way if you just ignore it.

IF you use partial installations, you should know that that PAM after being added to Slackware, it is not an optional thing, and YOU MUST install it.

Anyways, the PAM is just a method to manage in a centralized way the needs of the applications which interacts with system authentication. They use a conversation with PAM, instead of every program to implement and handle this authentication starting with "this login password is correct or not" .

From what I head, this permit to avoid many security issues which can end in a privilege escalation, because the code from applications which may be questionable, and that's why its way is much more secure.

However, PAM is not specialy for enterprise, like you believe. It is just a security thing. BUT, many confuse it with Kerberos, which is the thing used mainly in enterprises.

Originally Posted by brodo I just want to avoid problems when I upgrade my machine to the latest 32 bit current version.

Then remember to install the new packages pam, cracklib, and libpwquality (slackpkg install-new).

Will /etc/login.access feature be changed because of PAM, or stay the same?
Are there new rules now because of PAM, or the old rules work as usual with new backend?

What to do (on PAM system) with ACL that looks like this:
-:root daemon messagebus polkitd users:ALL EXCEPT LOCAL

Originally Posted by elcore Will /etc/login.access feature be changed because of PAM, or stay the same?

As far as I understand, this feature is now implemented in /etc/security/access.conf as part of PAM. This file is used by PAM module pam_access according to PAM documentation.

But I don't find any mention of module pam_access in any of the /etc/pam.d files.

As a test, I could suggest that, after configuring /etc/security/access.conf, you add this line in bold red in /etc/pam.d/system-auth (put the line at the exact location specified):

##################
# Authentication #
##################
#
auth        required      pam_env.so
auth        optional      pam_group.so
auth        sufficient    pam_unix.so likeauth nullok
auth        required      pam_deny.so
auth        optional      pam_gnome_keyring.so
[...]
account     required      pam_time.so           
account     required      pam_unix.so
account     required      pam_access.so
account     sufficient    pam_succeed_if.so uid < 100 quiet
account     required      pam_permit.so

If you do test, keep open a root TTY in case things go awry. However it should be fine because of the "optional" control of the added line.

[EDIT]: after a successful test, you should change "optional" to "required" in the pam_access.so line

[EDIT2]: pam_access.so should be configured as "account" service and not "auth". See next post

After looking at multiple examples on the web, it looks like the most appropriate way to implement pam_access.so in PAM configuration is with "account" service and not "auth" service.

Please do not take into account the proposed configuration of /etc/pam.d/system-auth in my previous post and use the following instead:

account     required      pam_time.so           
account     required      pam_unix.so
account     required      pam_access.so
account     sufficient    pam_succeed_if.so uid < 100 quiet
account     required      pam_permit.so

@gegechris99

Maybe, it shouldn't accept remote logins by default and a module should only be required to enable remote logins.
If the module required to block access is not installed, then it would appear it's wide open by default.
Just a thought, I'm really not looking to deploy PAM on my machines right now.

I understand that since firewall rules are not set by default, access module probably will not be set either.
However, when X listened for tcp by default; it was changed not to listen. So YMMV I guess.

Does using Slackware PAM require services like dbus and consolekit? Others?
I'm currently not using those services, and don't really want to.

Originally Posted by Xsane Does using Slackware PAM require services like dbus and consolekit? Others?

Did you even bothered to google about LinuxPAM before to ask this question?

No, LinuxPAM does NOT need DBUS or ConsoleKit2, it is just a thing built on top of "shadow" and extends its features.

Originally Posted by Xsane I'm currently not using those services, and don't really want to.

For someone who's wise and experienced enough to manage the impossible to use XFCE or KDE without running the DBUS and ConsoleKit2 services, I believe that the previous question is rather embarrassing...

I just installed -current on a laptop and have been trying to figure out the gnome-keyring. Google-chrome-stable wants to open gnome-keyring on startup. The solution I used before was "blank password" but I am now thinking that I want a password, but I don't want to be entering it just for occasional use of google-chrome. One is supposed to have some entries in the /etc/pam.d/ configurations, according to ArchLinux. Also, in Xfce, under Applications -> Settings -> Session and Startup -> Advanced -> Compatibility you can tick "Launch GNOME services on startup".

So now we have these updates in -current, per slackware64-current/ChangeLog.txt:

Sat Jun 13 20:40:31 UTC 2020 a/pam-1.4.0-x86_64-1.txz: Upgraded. IMPORTANT NOTE: This update removes the pam_cracklib and pam_tally2 modules. None of our current configuration files in /etc/pam.d/ use either of those, but if the configuration files on your machine do you'll need to comment out or remove those lines, otherwise you may experience login failures. a/shadow-4.8.1-x86_64-9.txz: Rebuilt. /etc/pam.d/system-auth: prefix lines that call pam_gnome_keyring.so with '-' to avoid spamming the logs about failures. a/sysvinit-scripts-2.1-noarch-32.txz: Rebuilt. rc.S: create /var/run/faillock directory for pam_faillock(8). a/util-linux-2.35.2-x86_64-2.txz: Rebuilt. /etc/pam.d/login: change the example for locking an account for too many failed login attempts to use pam_faillock instead of pam_tally2. l/imagemagick-7.0.10_19-x86_64-1.txz: Upgraded. l/libzip-1.7.1-x86_64-1.txz: Upgraded. n/openssh-8.3p1-x86_64-2.txz: Rebuilt. /etc/pam.d/sshd: change the example for locking an account for too many failed login attempts to use pam_faillock instead of pam_tally2.

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

Thanks