Might be a good move
Might be a good move
Posted Jun 27, 2025 23:08 UTC (Fri) by linuxrocks123 (subscriber, #34648)In reply to: Might be a good move by mjg59
Parent article: GNOME deepens systemd dependencies
> 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.
Posted Jun 27, 2025 23:16 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
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".
Posted Jun 28, 2025 3:13 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link]
Posted Jun 28, 2025 8:20 UTC (Sat)
by jem (subscriber, #24231)
[Link] (3 responses)
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.
Posted Jun 28, 2025 23:58 UTC (Sat)
by linuxrocks123 (subscriber, #34648)
[Link] (2 responses)
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.
Posted Jun 29, 2025 10:52 UTC (Sun)
by cortana (subscriber, #24596)
[Link] (1 responses)
"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!
Posted Jun 29, 2025 22:02 UTC (Sun)
by linuxrocks123 (subscriber, #34648)
[Link]
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move
Might be a good move