3 ms·

> Whoever wrote that does not know WTF they are talking about ... or they know something you don't.

therein 2mo ago
Quick, someone ask an LLM.
kazinator 2mo ago
Giving a the most flimsy reason for the policy doesn't give me confidence in that; I can think of much better reasons for disallowing uid aliases (root or otherwise). It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it. If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password. Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.
- imoverclocked 2mo ago
  I’m confused; Your entire response seems like reasons to not do this.
  - kazinator 2mo ago
    None of them apply to the situation of an individual operating an accessible system for their own use, or very small business with a handful of employees. The kind of organization where it would make sense to forbid tricks like multiple password entries pointing to the same user (such as UID 0) is going ot be the kind of organization where the whole thing is moot anyway in connection with SSH, because in those kinds of organizations, you don't want ad hoc machines to be accessible via SSH publicly. You don't want employees to be solving the problem of SSH ports being probed: do we use fail2ban, port knocking, kazinator's user name tricks posted on HN? ... just no! You have some kind of perimeter VPN. Authorized users connected to the VPN can then use SSH to machines inside the secured zone. It makes no sense to bring up corporate rules against my solution which for a problem that corporations should not have in the first place: SSH-accessible machines on the open internet being probed.

Quick, someone ask an LLM.

Giving a the most flimsy reason for the policy doesn't give me confidence in that; I can think of much better reasons for disallowing uid aliases (root or otherwise). It has the same optics as an unauthorized entry someone planted: a backdoor to retain root access. It will continuously have to be explained to new people who spot it. If the intent is to keep the passwords identical (which it probably should be), the tooling doesn't support it. When someone changes the password for root using standard tools, the one for rotorooter doesn't sync. This is a problem if someone is changing the password in order to restrict access to just a specific set of people who know the new password. The unaltered entry turns into a de facto backdoor for everyone knowing the old password. Pitafall: if you put an alias entry in the wrong spot in in the password file, so that it appears before the canonical entry, then UID 0 maps backward to the alias name (e.g. via the getpwuid() function). This breaks all logic that looks for the string "root" rather than UID 0. E.g. shell scripts looking for root in the output of some command.

imoverclocked 2mo ago
I’m confused; Your entire response seems like reasons to not do this.
- kazinator 2mo ago
  None of them apply to the situation of an individual operating an accessible system for their own use, or very small business with a handful of employees. The kind of organization where it would make sense to forbid tricks like multiple password entries pointing to the same user (such as UID 0) is going ot be the kind of organization where the whole thing is moot anyway in connection with SSH, because in those kinds of organizations, you don't want ad hoc machines to be accessible via SSH publicly. You don't want employees to be solving the problem of SSH ports being probed: do we use fail2ban, port knocking, kazinator's user name tricks posted on HN? ... just no! You have some kind of perimeter VPN. Authorized users connected to the VPN can then use SSH to machines inside the secured zone. It makes no sense to bring up corporate rules against my solution which for a problem that corporations should not have in the first place: SSH-accessible machines on the open internet being probed.