Might be a good move [LWN.net]

Might be a good move

Posted Jun 26, 2025 6:51 UTC (Thu) by linuxrocks123 (guest, #34648)
In reply to: Might be a good move by jem
Parent article: GNOME deepens systemd dependencies

Okay, so, before I get into this again, I hope you guys realize that the weird auth tricks you're saying XDM can't do are all also things the login program running on the gettys couldn't do and that creating a setup where the gettys on your machines all are broken would be an insane thing to do.

(Fortunately, XDM actually can do the weird auth tricks, because PAM is in charge of all of the weird auth tricks, and login can use PAM, too.)

> The greeter needs to prompt the user to insert the token (USB key or smart card), and after that prompt for the PIN code.

The primary enterprise 2FA security theater crap I've encountered has been in the form of "install this stupid app on your phone, and, when you try to log in, we will hang the login until you respond to a notification on your phone." The greeter obviously has no role in that.

The greeter also has no role in the alternative 2FA security theater I encountered when I told an organization I didn't have a cell phone that would work with the app they wanted me to use, so they sent me a Yubikey USB device where you press a button and it spits out a bunch of letters. If someone wanted to use that with PAM, they could claim the USB keyboard device created when a Yubikey is plugged in and hang the login until the button is pressed and the letters are spit out.

Since those are the only two situations I've personally encountered, I'm unfamiliar with the enterprise 2FA security theater crap you're describing. If you're using a password, a PIN, and a smart card all together, that would be 3FA in a way which seems pointless because the password and PIN are duplicative factors. But, I guess PAM could probably take the PIN and password munged together if someone really wants that. For this smart card, it looks like there's a PIN but no password, so you can just put the PIN in the standard password field: https://docs.oneidentity.com/bundle/safeguard-authenticat...

> The greeter also needs to respond to errors, like if an invalid token is inserted or the wrong PIN code is entered.

PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

to post comments

Might be a good move

Posted Jun 26, 2025 7:21 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (13 responses)

> creating a setup where the gettys on your machines all are broken would be an insane thing to do

? No, this is an entirely normal thing. There's an expectation that the login environment be able to present things through audio, to change the colours it's presenting, to support touchscreen text entry, to support eyetracking input devices. There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

But even outside accessibility, yes, complex authentication is expected to fail in simpler environments. How does a console interface interact with PAM in such a way that you can choose which of the multiple authentication mechanisms with it should trigger with appropriate UI guidance? How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition? You may not care about these use cases, but the people deploying Linux in enterprise environments (including me) do.

Might be a good move

Posted Jun 26, 2025 14:24 UTC (Thu) by linuxrocks123 (guest, #34648) [Link] (12 responses)

> There's a whole bunch of accessibility requirements that can never be satisfied by a text console, and that's just fine.

Text console is one of the most inherently accessible interfaces for the blind because it is extremely easy to do text-to-speech with. I recently read a blog post by a blind Linux user in which he lamented that he's recently had to switch back to the console since GUI accessibility is degrading as GTK4 was adopted more, since GTK4 was released with some bad accessibility bugs. Unfortunately, I can't find it now. I think it was on BlueSky.

> How does your getty login manage user choice of whether to use a password, fingerprint, or facial recognition?

First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field. You could put those instructions in /etc/issue for user friendliness, right below your standard enterprise all-caps threat that I'm sure is already there. (You know what I mean, that "ATTENTION: IF YOU DO SOMETHING WE DON'T LIKE WE WILL MAKE SURE YOUR LIFE BECOMES A LIVING A HELL" thing.)

Might be a good move

Posted Jun 26, 2025 17:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (11 responses)

> Text console is one of the most inherently accessible interfaces for the blind

That's great, except you can't run a modern browser there so you're cut off from most of the world. But even then, accessibility isn't purely about people being blind, there's a giant array of other accessibility mechanisms that can't possibly work in a text-only world. Someone who needs to use an eye-tracking on-screen keyboard isn't going to do very well at the console.

> First thought that came to the top of my head was to put linuxrocks123-pass, linuxrocks123-finger, or linuxrocks123-facial in the the username field

Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use? That'd probably work, and now we're starting down the road that gets you to the level of complexity modern graphical login environments have.

Might be a good move

Posted Jun 26, 2025 21:01 UTC (Thu) by linuxrocks123 (guest, #34648) [Link] (10 responses)

> That's great, except you can't run a modern browser there so you're cut off from most of the world.

https://www.brow.sh/
https://github.com/fathyb/carbonyl

> Ah, so we'd encode additional logic into getty to parse out the PAM stack it should use?

No, "getty" (you actually mean "login") wouldn't change. PAM would interpret the username and decide what to do based on the suffix. Or, if you don't like that, I guess you could type one of the actual password, "finger", or "facial", to select what you want to do at the password prompt.

Or you could just use pam_any to try all of them at once: https://github.com/ChocolateLoverRaj/pam-any

That would probably best for that situation.

Might be a good move

Posted Jun 26, 2025 22:28 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (7 responses)

You're narrowly focusing on one aspect of accessibility and ignoring the much wider spectrum (there are people who use screen readers but still have enough vision that presenting them with graphics is worthwhile, for instance) which leaves me pretty convinced you don't actually care about accessibility - a text only interface is an option for a set of people who need accessibility features, and entirely unusable for another set. A graphical login system needs to handle those situations, which means it needs more complexity.

And shoving this into PAM in the way you describe breaks any users who have hyphens in their username, and running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader. The complexity that exists isn't gratuitous, it solves real problems for real people. You don't need to care about those problems, and you're free to run software that doesn't solve them. But I *need* software that solves these problems because I have users and policies that have these requirements and telling me that this software shouldn't exist doesn't make my problems go away.

Might be a good move

Posted Jun 27, 2025 23:08 UTC (Fri) by linuxrocks123 (guest, #34648) [Link] (6 responses)

If your usernames have hyphens then yeah type it in the password field.

> running everything in parallel provides no indication to the user what they should be trying and is going to be confusing if the face recognition fails because they're looking down at their keyboard to find the fingerprint reader.

As long as they find the fingerprint reader, they won't have a problem. pam_any is successful if *ANY* of the authentication options succeeds.

> The complexity that exists isn't gratuitous, it solves real problems for real people.

Agree to disagree.

> But I *need* software that solves these problems because I have users and policies that have these requirements

Not users, I wouldn't think, but, I am sure you have *policies* with those requirements, likely the same *policies* that gave CrowdStrike's customers so many problems a year ago (and serves them right, I'd say).

> telling me that this software shouldn't exist doesn't make my problems go away.

A problem doesn't exist because software that meets stupid requirements doesn't exist. A problem exists because someone has stupid requirements in the first place. Now, if you can't solve the "someone has stupid requirements" problem, then sure, maybe you do need to use or create software that meets the stupid requirements as a workaround.

But can't you at least cordon the stupid software off from the rest of the system and not make it the default? Must you really expand the attack surface of the login prompt so much that you then have to take heroic measures to give each individual login prompt its own UID to protect it from *other instances of itself*?

I'd say no. I'd say let the enterprise buffoons write their own greeter and maintain it themselves. But, I'm on Slackware, so none of this is my problem anyway.

Might be a good move

Posted Jun 27, 2025 23:16 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Agree to disagree.

That's not how it works.

"Agree to disagree" is only appropriate in situations when both sides have presented compelling, non-mutually-exclusive arguments, but can't decide *which* arguments have more weight. You haven't presented any, short of "I don't have that problem, so I don't care about solving it".

Might be a good move

Posted Jun 28, 2025 3:13 UTC (Sat) by linuxrocks123 (guest, #34648) [Link]

Agree to disagree :P

Might be a good move

Posted Jun 28, 2025 8:20 UTC (Sat) by jem (subscriber, #24231) [Link] (3 responses)

Let me tell you about a two factor authentication system I'm familiar with. In this system, every user has a smart card. To log in to a workstation, they insert the card into the reader and, if the card is valid, a PIN entry pop-up is displayed. After entering the correct PIN they are logged in.

No field for entering a user name is displayed, the user is identified from the certificate the card sends when the negotiating with the system. The backend system also checks that the user is authorized to log in by examining the certificate (which is digitally signed.)

The card also functions as a visual ID badge. When the user leaves their desk, they have to remove the card from the reader and carry it with them. This automatically locks the workstation.

Why a smart card? A smart card is designed to follow the Unix principle: do one thing, and do it well. The "one thing" in this case is to be a unique, extremely hard to forge physical token, designed to protect the private key of the user. A smart card also has a very small attack surface: a serial interface with a limited command set.

This system is in use all over the public sector here, nation wide. It has been in use for at least 15 years now. The workstations are running Windows, of course. Trying to sell a "Public sector Linux OS" as a replacement with this functionality haphazardly shoehorned into an XDM-like user interface is doomed from the beginning. That ship sailed a long time ago.

Might be a good move

Posted Jun 28, 2025 23:58 UTC (Sat) by linuxrocks123 (guest, #34648) [Link] (2 responses)

That sounds like both a cool setup and a fancy way to waste taxpayer money. Not super secure to be using a PIN instead of a password as the second authentication factor, though.

You could certainly make that work on Linux without any changes by just leaving the username empty and typing a password for the PIN, so I'm not sure why at you think it would present a problem for a standard greeter or why support would need to be "shoehorned". However, if you wanted to make the login UX superb, with a whizz-bang popup window saying "Hello <Name>" like you described, you could certainly make a custom greeter that watches for the device to be plugged in and then uses PAM to authenticate after plugging it in. You could do the auto-locking thing with a few custom udev rules and a script to do xscreensaver-command --lock when the key is removed.

Whether or not you wrote a custom greeter, you'd want the complexity in PAM so that people can still unlock xscreensaver by plugging in the device and typing the PIN in the xscreensaver password field.

In the end, these problems are not hard. There's no reason for these programs to be complex, and there are good reasons for them not to be.

Might be a good move

Posted Jun 29, 2025 10:52 UTC (Sun) by cortana (subscriber, #24596) [Link] (1 responses)

> Not super secure to be using a PIN instead of a password as the second authentication factor, though

"PIN" does not imply "4 numeric digits". But in any case - the smart card will only allow authentication attempts at a configured rate, and will lock down, preventing any further attempts after a certain number of failures.

> You could certainly make that work on Linux

sssd already implements all this AFAIK. At least, what jem describes is exactly how I use my YubiKey, except that I haven't enabled the option to lock the screen when it's unplugged, because I'm using this on my home systems and I often do want to have my laptop and desktop both active at the same time!

Might be a good move

Posted Jun 29, 2025 22:02 UTC (Sun) by linuxrocks123 (guest, #34648) [Link]

Good to know. It looks like pam_sss is the module that bridges sssd to standard login programs: https://linux.die.net/man/8/pam_sss

Might be a good move

Posted Jun 27, 2025 6:21 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

> That would probably best for that situation.

Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

NB: using expletives to describe these requirements ("security theater crap") and/or systemd and/or its implementation, goals or whatever doesn't help your case either.

Might be a good move

Posted Jun 27, 2025 23:14 UTC (Fri) by linuxrocks123 (guest, #34648) [Link]

> Please accept the fact that there are many people out there who do not think, for various reasons (not all of which can be argued away), that "that situation" is acceptable these days.

I don't think you're understanding the thread. There's a hypothetical situation where someone wants to do really weird auth, and we're talking about whether using PAM, which would work with every greeter, is better for that situation, or if it's better to create a greeter that handles the weirdness in the greeter itself. I hope that helps.

Might be a good move

Posted Jun 26, 2025 22:32 UTC (Thu) by elsandosgrande (subscriber, #174457) [Link] (2 responses)

> PAM will just fail the login if that happens. An administrator could find the reason in the logs if it keeps happening.

Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

Might be a good move

Posted Jun 27, 2025 23:27 UTC (Fri) by linuxrocks123 (guest, #34648) [Link] (1 responses)

> Do you mean that the login manager shouldn't report errors to the user at all, that it should just report a generic “login failed” error and that the user or administrator then should look in the system log(s) to see the details of said failure, or …? Neither of the two interpretations of your statement that I can think of right now sound like a great user experience compared to the login manager giving the user at least a bit more information regarding login failures.

mjg59 got into a bit of a stupid argument about whether it would work at all, not whether it would work well. Yes, of course an ideal greeter would say why the login failed. pam_info is the function that allows that message to be printed, but it has some prereqs that mean I don't think it actually works with the current versions of login and xdm. I expect that would be easy to fix if someone wanted to fix it.

Might be a good move

Posted Jun 28, 2025 23:59 UTC (Sat) by linuxrocks123 (guest, #34648) [Link]

Meant to say "mjg59 and I got into a bit of a stupid argument"