PAM about to be merged in -current

mlangdn · 05-19-2020, 02:19 PM

I don't need root to login via sddm. I simply want my passwordless login back for me as a user. I'm the only user on this box. I am used to the convenience.

bassmadrigal · 05-19-2020, 02:40 PM

Quote:

Originally Posted by Alien Bob

In two Plasma5 packages, I reverted changes made by developers who thought they could decide for the users about how root should be used.
Sure, I want to be able to run programs as root in my graphical desktop which I am running as a regular user. On the other hand I consider it bad practice if someone logs on as root, directly into the graphical desktop. I will however not try to prevent anyone from doing so. It's OK if you want to practice badness, as long as you don't bother me with the fallout.

Logging on as root into Plasma5 using SDDM is not something I blocked. It is a PAM configuration which has not been fleshed out. SDDM ships with PAM configuration files that target Arch Linux and they did not work for Slackware, so I wrote mu own. Perhaps I missed something.
If anyone contributes a patch or instructions on how to change the PAM configuration so that root can login through SDDM, I will add that. But I don't feel the desire to spend time to research this myself. You want this? You tell me how to configure it correctly.

I didn't realize you had made your own PAM config files, but your stance on not searching for a fix but supporting one if someone can provide the details is what I'd expect and reasonable. Thanks for your great work on this so far!

denydias · 05-19-2020, 03:47 PM

Quote:

Originally Posted by Alien Bob

But I don't feel the desire to spend time to research this myself. You want this? You tell me how to configure it correctly.

Does the same applies to autologin (not as root, not passwordless)?

mlangdn · 05-19-2020, 04:01 PM

The config file /etc/pam.d/kde-np does not exist. Creating this file and populating with

Code:

#%PAM-1.0
# Begin /etc/pam.d/kde-np

auth     requisite      pam_nologin.so
auth     required       pam_env.so

auth     required       pam_succeed_if.so uid >= 1000 quiet
auth     required       pam_permit.so

account  include        system-account
password include        system-password
session  include        system-session

# End /etc/pam.d/kde-np

did nothing to help. I suppose that plasma-workspace needs to be rebuilt with this added.

Pithium · 05-19-2020, 04:22 PM

FWIW a KDE developer finally managed to chime in on the root login issue:
https://forum.kde.org/viewtopic.php?...124502#p328070

According to the above thread, SDDM explicitly disables access to the root user. Even if you find a way to trick it into showing root, still won't let you due to other safeguards. I assume this is internal to SDDM itself, and cannot be resolved in configuration of other packages.

Any attempt to question this appears to result in some pretty arrogant behavior from devs and other users.

drgibbon · 05-19-2020, 04:40 PM

Quote:

Originally Posted by Pithium

According to the above thread, SDDM explicitly disables access to the root user. Even if you find a way to trick it into showing root, still won't let you due to other safeguards. I assume this is internal to SDDM itself, and cannot be resolved in configuration of other packa.ges.

Any attempt to question this appears to result in some pretty arrogant behavior from devs and other users.

Did you read the whole thread? The "let me log in as root" crowd seemed rather obnoxious/hyperbolic to me..

Pithium · 05-19-2020, 05:08 PM

Quote:

Originally Posted by drgibbon

Did you read the whole thread? The "let me log in as root" crowd seemed rather obnoxious/hyperbolic to me..

Yes, I read the entire thread. I also read a number of other threads, spanning a number of years. When someone asks question A, people respond with the answer to question B. People want to log in as root for a variety of different reasons, and yet every time they bring the issue up people respond as if it's their first time using a computer.

I linked that particular thread because someone marked as a developer by the forum software actually chimed in and declared a position. Most other forums result in a mini flame war where the question never actually gets answered. From what I've seen the obnoxious behavior on this topic comes from both sides. Don't be surprised when someone gets a little hot and bothered if you blatantly refused to read the question that was asked.

Frankly I find the arguments for root access to be just as flawed and opinionated as those against. So I look for someone with actual input, such as a KDE developer.

rkelsen · 05-19-2020, 05:09 PM

^ That answers that.

While I generally prefer Eric's approach (i.e. It's not smart, but I won't stop you), I think in this case they're correct. If you learn how to use it properly, then you shouldn't ever need to log in to the GUI as root anyway.

That's not arrogance, it's common sense.

That aside, there are several work arounds for this "limitation."

LuckyCyborg · 05-19-2020, 05:38 PM

Quote:

Originally Posted by rkelsen

That's not arrogance, it's common sense.

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

drgibbon · 05-19-2020, 05:49 PM

Quote:

Originally Posted by LuckyCyborg

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

Yeah, except this is Linux/libre software, not a proprietary world where there's only one way. Use a different login manager or fork.

LuckyCyborg · 05-19-2020, 05:58 PM

Quote:

Originally Posted by drgibbon

Yeah, except this is Linux/libre software, not a proprietary world where there's only one way. Use a different login manager or fork.

Exactly that I did, using the KDM of KDE4, after removing the Plasma5 from my USB hard drive, and fully rolling back to stock Slackware.

I love Plasma5, but that particular installation in the USB hard drive was made for specific administrative tasks - and running as root is a requirement.

Now, I wonder what to do with my boxes having Plasma5, which are still "frozen" in a pre-May 18 state...

drgibbon · 05-19-2020, 06:12 PM

Quote:

Originally Posted by LuckyCyborg

Exactly that I did, using the KDM of KDE4, after removing the Plasma5 from my USB hard drive, and fully rolling back to stock Slackware.

Quote:

Originally Posted by LuckyCyborg

I love Plasma5, but that particular USB hard drive was made for specific administrative tasks - and running as root is a requirement, in my vision.

Have you tried these guys? Ok I'm sorry, just kidding, no more I swear

I'll leave the thread to legitimate stuff about the new PAM, which so far for me has been completely unnoticeable. I seem to remember some fun stuff from Yubico needing PAM, and also unlocking an encrypted home directory upon X login which should now be possible

Pithium · 05-19-2020, 06:14 PM

Quote:

Originally Posted by LuckyCyborg

Yes, I agree - it's common sense, but a Microsoftian common sense.

So, you lock the software from my own computer, offering me limited rights to use my own computer, considering that you know better than me what is better for me?

That appears to be the decision of the SDDM devs, yes. Of course the thread I linked is a few years old, so maybe it's a topic worth reopening with them. I haven't actually checked the issue trackers for an official request. That said, most desktop distros have already gone the path of disabling root logins entirely. Servers don't typically run X anyway so that leaves slackware as part of a small collection of desktop distros that would even notice that it's missing.

sddm.conf already has the functionality to restrict user access via a number of options. All that needs to happen is a configuration parameter to enable root login, with the default set to disabled. If I ever figure out how to implement that change, I will since I see no benefit in completely blocking this functionality.

I find it more likely that someone got a little overzealous and simply added some stupid check to block the signal when the username is root. Probably thinks he's doing everyone a favor but he's really not.

LuckyCyborg · 05-19-2020, 06:44 PM

A friend of mine, who use Fedora, was kind to take a look to our PAM files for SDDM, and he given me the configs bellow.

/etc/pam.d/sddm

Code:

#%PAM-1.0

auth       include      system-auth
auth       include      postlogin

account    include      system-auth

password   include      system-auth

session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_keyinit.so force revoke
session    include      postlogin

/etc/pam.d/sddm-autologin

Code:

#%PAM-1.0

auth       requisite    pam_nologin.so
auth       required     pam_env.so
auth       required     pam_permit.so

account    include      system-auth

password   include      system-auth

session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_ck_connector.so nox11
session    include      postlogin

/etc/pam.d/sddm-greeter

Code:

#%PAM-1.0

# Load environment from /etc/environment and ~/.pam_environment
auth            required pam_env.so

# Always let the greeter start without authentication
auth            required pam_permit.so

# No action required for account management
account         required pam_permit.so

# Can't change password
password        required pam_deny.so

# Setup session
session         required pam_unix.so

Considering that he made them in no more than 10 minutes, there's no guaranty about consistency or inner security.

BUT with those configs, the SDDM looks like working fine both as autologin to whatever user including root, and as manual root login.

Feel free to test them, AFTER YOU DID A BACKUP OF YOUR ORIGINAL FILES.

Still, we talk about PAM here - a thing which have no remorse to lock you out.

Pithium · 05-19-2020, 07:12 PM

I stand corrected. SDDM is not blocking the login request for root at all, instead choosing to fail with log output:

Code:

16:57:50.227] (II) HELPER: [PAM] Starting...
[16:57:50.227] (II) HELPER: [PAM] Authenticating...
[16:57:50.227] (II) HELPER: [PAM] Preparing to converse...
[16:57:50.227] (II) HELPER: [PAM] Conversation with 1 messages
[16:57:51.824] (WW) HELPER: [PAM] authenticate: Authentication failure
[16:57:51.825] (II) HELPER: [PAM] returning.
[16:57:51.825] (WW) DAEMON: Authentication error: "Authentication failure"

The only hardcoded user check I found is for sddm, all others are passed through to PAM using the same function calls. I don't know anything about PAM but this makes me feel better about the code itself. Not as microsoftian as the discussions make it seem

For the record I'm not saying it should allow root logins.. It's just nice to know that an SDDM fork isn't needed.