> If anyone wants to rewrite PAM in Rust... :-D

If you do, offer support for writing modules in a scripting language like Lua or Python. PAM could make it a lot easier to just add OAuth with your company IdP, for example…

Ah, but then you choose the wrong language or language runtime and distros ship old versions for 10+ years :)

(compare: polkit. Both sides have their point, but I've been annoyed by this standoff a few times).

> You don't get the whole "why are you overturning 46 years of tradition??" nonsense

Respectfully, we are the opposing sides of the barricades here. I was removing sudo-rs, uutils and some of the systemd-* packages from fresh Ubuntu installations until the amount of virtue signaling got really tiresome.

Currently almost no Ubuntu left in my production. Hopefully Debian will not package those.

PS: Rust is awesome!

> There's no reason for it

The reason is to add a delay when bruteforcing passwords.

Bruteforcing is only really done with the password hashes in hand. Attacks on live systems are done with credential stuffing.

Definitely not for local password authentication, and I'm dubious it helps for ssh either. See my other comment.

Not for local password authentication.

https://github.com/pibara/pam_unix/blob/master/unix_chkpwd.c...

Yes, for local password authentication.

The code you linked to isn't the code for a wrong password. It's a check to make sure you're using a TTY. That code isn't to prevent brute force. The delay there is 10 seconds.

The 2 second delay is in support.c at https://github.com/pibara/pam_unix/blob/5727103caa9404f03ef0...

It only runs if "nodelay" is not set. But you might have another pam module setting its own delay. I have pam_faildelay.so set in /etc/pam.d/login

Change both the config files and you can remove the delay if you want.

> Yes, for local password authentication.

It's really really not. By default PAM has a difficult-to-disable 2ish second minimum delay for all authentication methods. However this is completely pointless for local password authentication because PAM checks password using unix_chkpwd, which has no delay. The comment I linked to is explaining that unix_chkpwd has a silly security theatre delay if you try to run it in a tty, but that's trivial to avoid.

If you want to brute force local password authentication you can just run unix_chkpwd as fast as you like. You don't need to involve PAM at all, so its 2 seconds delay achieves nothing.

It maybe does more for remote connections but I'm not sure about that either - if you want to check 10k ssh passwords per second what stops you making 10k separate connections every second? I don't think the 2 second delay helps there at all.

> Change both the config files and you can remove the delay if you want.

This is extremely complicated. See the comments in the issue for details.

No, it's very simple. Do what I said in my comment. Add nodelay to the options for pam_unix.so and set pam_faildelay.so delay=0

That's it. You didn't link to any issue and the weird mistakes and justifications you're making feels like arguing with an LLM.

You obviously can't run unix_chkpwd against a local account without root.

> You obviously can't run unix_chkpwd against a local account without root.

Wrong. At least check before you say something is obvious.

> No, it's very simple.

Even more wrong: https://github.com/linux-pam/linux-pam/issues/778#issuecomme...

> feels like arguing with an LLM

I could say the same about you, repeatedly and confidently asserting falsehoods.

No, I'm right. You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash. If you think you can, explain how. Otherwise you have to use the setuid version which won't let you run it directly.

And I just removed the delay using my method. Perhaps try checking something yourself?

I don't understand how you can be so confidently wrong about something so easily checked. :D

> You can't run unix_chkpwd against a local account without root because you won't be able to access /etc/shadow to get the hash.

unix_chkpwd can access /etc/shadow because it is suid.

> Otherwise you have to use the setuid version which won't let you run it directly.

Haha you mean this?

  $ unix_chkpwd
  This binary is not designed for running in this way
  -- the system administrator has been informed

Take a look at the source code I linked about 6 comments ago!

> Perhaps try checking something yourself?

I have. You haven't.

  printf 'hunter2\0' | unix_chkpwd yourusername nullok; echo $?