PAM about to be merged in -current

Richard Cranium · 05-22-2020, 06:50 PM

Quote:

Even though KDE Plasma5 and SDDM are not part of Slackware (yet), it is still meant to get included at some point, and then it is up to the user to feel carefree and login as root into a graphical desktop. I would not want ever to do that, but as long as you do not hold me responsible if someone hacks your network because you had an urge to login as root instead of a regular user... it's your party.

And if I have a virtual machine somewhere that I use as a build server, I might actually want to log in as root in a graphical environment in case one of the tools I use for the build is attempting to launch a GUI when I ssh into said build server and run certain commands. Otherwise, I will never be able see that GUI and will wonder why whatever-it-was-I-was-doing failed.

By all means, provide a popup or whatever that tells me both that I am a moron for wanting to do that and that any horrible damage on my system to due to me being a moron. Odds are that I'll whine about that eventually, but you'll be covered.

rkelsen · 05-22-2020, 07:59 PM

Quote:

Originally Posted by mlangdn

@LuckyCyborg and @gegechris99 - thanks for the tips and configs. My unprivileged user has the autologin back.

@mlangdn Can you please post what you did?

mlangdn · 05-22-2020, 08:36 PM

Quote:

Originally Posted by rkelsen

@mlangdn Can you please post what you did?

In Post #157, LuckyCyborg posted three config files. I copied the first two into place, but I did not use sddm-greeter per gegechris99. I opened System Settings > Startup and Shutdown > Login Screen (sddm), then clicked the advanced tab and selected Automatically login as user [michael] with session [plasma]

Rebooted.

Alien Bob has three new configs that would probably work better and most definitely would be in line with the Slackware way. He recommends using sddm-greeter. I defer to him and will probably use his configs tomorrow. Time now for a drink or two or three or......

lioh · 05-23-2020, 05:18 AM

@GazL

also with your config listed in #163 I am not able to unlock gnome-keyring when using XDM as a display manager. '/usr/bin/gnome-keyring-daemon --daemonize --login' is started correctly (which is also the case with the Slackware default config) but the login keyring does not get unlocked automatically. Does it work for you with XDM?

GazL · 05-23-2020, 06:33 AM

it seems to work if you do this, letting pam start it. I've not had much success playing with starting it from xsession/xinitrc

Code:

# /etc/pam.d/xdm:
auth            requisite       pam_nologin.so
auth            include         system-auth
auth            optional        pam_group.so
-auth           optional        pam_gnome_keyring.so
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         required        pam_loginuid.so
-session        optional        pam_ck_connector.so
-session        optional        pam_gnome_keyring.so auto_start

This relies on changing auth part of system-auth to just:

Code:

##################
# Authentication #
##################
#
auth        required    pam_env.so
auth        required    pam_unix.so likeauth nullok

##################
...

You'll see a "ws1 xdm[5968]: gkr-pam: unable to locate daemon control file" in /var/log/secure. From a google search I've found this is because XDG_RUNTIME_DIR isn't set when the gnome_keyring module is run (apparently its set by pam_systemd on systemd systems and as usual with gnome, no one cares about non-systemd systems)

To be honest, the whole thing, like most things gnome/freedesktop.org, looks more messy the closer you look at it. I don't think I'll bother using the keyring.

lioh · 05-23-2020, 06:56 AM

Dear GazL.

Thanks for the hints. I can confirm that it works as described, including the mentioned errors in secure log.

Greetings
Lioh

lioh · 05-23-2020, 03:08 PM

Hi again,

I have noticed that ConsoleKit2 does not seem to be launched anymore which causes a few side effects. E.g. usually I use the following Reboot Command for non-root users:

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

Which now results in Error org.freedesktop.ConsoleKit.Manager.Error.InsufficientPermission: Not Authorized.

I am not sure if my Thunar gfvs issue might also be related to that.

Btw. back to the stock PAM config, so no modifications from my side.

Greetings
Lioh

dchmelik · 05-23-2020, 05:48 PM

Everything changed with Pluggable Authentication Modules (PAM, not just potentially breaking when upgrades required PAM; ) that aspect is like Debian & RedHat operating system (OS) distributions (distros,) etc., now. After upgrade, passwd forces non-blank password. That's not classic Unix-like; it's always been system administrator (sysadmin) knows/decides (not a third party; newer software) which systems/accounts need passwords or not; they're certainly always not always necessary.

Let's just have default classic Unix-style. FreeBSD Unix has had PAM some time (apparently) but does it right: setup asks if you even want password authentication, then whether you even want a password... choices remain default when adding accounts (if NetBSD has PAM, probably same--as older and not only intended for servers, but PCs--but OpenBSD of course isn't, as firstly security-/server-oriented.)

LuckyCyborg · 05-23-2020, 06:38 PM

Quote:

Originally Posted by dchmelik

What's next, RedHat agenda (systemd, PAM) software says "unencrypted filesystem: installation not allowed?!"

My guess is that this boat sails to: Slackware Linux Enterprise Desktop 1.0

dchmelik · 05-23-2020, 07:58 PM

Quote:

Originally Posted by LuckyCyborg

What Mr. Hameleers did is another story, is his personal "War on Root Desktop" and I respect his position as packages builder, but in the end, we'll see if those strong-hand configs against root desktop will end in Slackware...

It seems you're only discussing it in the case of KDE's & XFCE's display managers? I don't like KDE & XFCE anymore and if they did this, I may never recommend them again.

You're free to use other/simpler X like tab window manager (TWM,) etc. as root, right? If so, don't blame alienBOB... the mess PAM/KDE developers made isn't his fault.

It's best to run X non-root, but I still needed to configure styles for programs running as root, like systemsettings, KATE, 'Dolphin (superuser mode... which I guess that mode won't be available anymore?,)' or whatever I want...

LuckyCyborg · 05-23-2020, 08:50 PM

Quote:

Originally Posted by dchmelik

It seems you're only discussing it in the case of KDE's & XFCE's display managers? I don't like KDE & XFCE anymore and if they did this, I may never recommend them again.

You're free to use other/simpler X like tab window manager (TWM,) etc. as root, right? If so, don't blame alienBOB... the mess PAM/KDE developers made isn't his fault.

It's best to run X non-root, but I still needed to configure styles for programs running as root, like systemsettings, KATE, 'Dolphin (superuser mode... which I guess that mode won't be available anymore?,)' or whatever I want...

Well, it's "only" about the PAM config files for SDDM, where initially Mr. Hameleers tried to lock out the root login.

All sorted now, by myself with the help of a friend which is Fedora user, and later by Mr. Hameleers, who proposed better PAM config files for SDDM.

bassmadrigal · 05-23-2020, 09:16 PM

Quote:

Originally Posted by dchmelik

After upgrade, passwd forces non-blank password.

Pretty sure I remember reading that you just need to pass -d to passwd to allow a passwordless login (if that's what you mean by a non-blank password).

Code:

passwd -d $user

dchmelik · 05-23-2020, 09:21 PM

Quote:

Originally Posted by bassmadrigal

Pretty sure I remember reading that you just need to pass -d to passwd to allow a passwordless login (if that's what you mean by a non-blank password).

Code:

passwd -d $user

Forcing it (not the case through 14.2) then having to do that isn't good.

LuckyCyborg · 05-23-2020, 09:44 PM

Quote:

Originally Posted by dchmelik

Forcing it (not the case through 14.2) then having to do that is not good enough (but up to 14.2 and FreeBSD w/PAM is.)

Please stop comparing Slackware, which is a Linux distribution, with a BSD distribution!

When you adopt a cat, you expect it to mew to you, not to bark to you...

Looks like you want a cat which barks.

dchmelik · 05-23-2020, 10:16 PM

Quote:

Originally Posted by LuckyCyborg

Please stop comparing Slackware, which is a Linux distribution, with a BSD distribution!

Off-topic/unhelpful; you didn't read/comprehend some my post: Slackware-stable since original--almost 30 years--even now, when creating users, doesn't force passwords. Strictly Unix[-like] OSes never do--classic Unixes, other GNU/Linuxes before systemd (or before popularity of PCs)--so Slackware-stable is like all in ways, but Slackware-current isn't: forces passwords, like Debian & RedHat... do you see now? When I mentioned FreeBSD Unix it's just referencing the top current-day Free/Libre/Opensource Software (F/LS, OSS, FOSS, FLOSS) Unix using PAM right (doesn't force passwords) that can be examined. Some software is used across all POSIX-based... The point is to be like Unix workstation when necessary so see how others are (even *BSD: nothing wrong with it.) and not newer GNU/Linux.

Quote:

Sorry, probably is just a cultural conflict, but as someone born, raised as Russian and living his entire life in the Russian Federation, I cannot appreciate that enforcing of my rights limitation on something which is my own property: my own computer.

I completely understand/empathize that (family from related culture) but apparently you don't understand/care others' have same problem... rights limitation (blank passwords) for their own property: their own computers.