From reading the man page of lastlog:

-m, --maximum MAX
Set maximum number of login failures after the account is disabled to MAX. Selecting MAX value of 0 has the effect of not placing a limit on the number of failed logins. The maximum failure count should always be 0 for root to prevent a denial of services attack against the system.

I don't understand the last part in bold.
1) If a root account it locked out because the MAX failure count has been reach, and the system denies access to root login- would this repeated action be enough to bog down the system enough to be considered a denial of services attack?

2) If denying root after it's locked out repeatedly can be considered a DOS attack, couldn't this happen equally for locked out non-root user login attempts?

As I read it root should be exempt from having a maximum set so it can be accessed always. This isn't as bad as it sounds as the account should never be allowed to log in over any network connection anyway.

No, but I am curious on the logic of how root not being able to authenticate could lead to DOS attacks. If that is true, then the same could be for any user being rejected during logon, right?

However, I was thinking....could the root account locked mean services/daemons not able to run? Do daemons/system services run with EUID 0?

No, it's the other way around: root no longer being able to authenticate can be the effect of a DOS. And unprivileged accounts are not as equally important as privileged accounts: root isn't just an account best confined to only system administration but also a set of capabilities ('man capabilities') required to perform certain operations.


IMO that's something you could easily test or strace yourself. Do services running as daemon require authentication when starting?


Are you telling me your 'ps' doesn't support "-o euid"?