Might be a good move [LWN.net]

Might be a good move

Posted Jun 26, 2025 7:21 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Might be a good move by linuxrocks123
Parent article: GNOME deepens systemd dependencies

> 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.

to post comments

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.