Another account with same uid as root gets prompted to set new password for root, not itself

Question

After upgrading the os from 5300-06 to 5300-11, this weird behaviour happened.

My system had another unix account, let's call it "abc", purposely configured its uid to 0 for working as a root with all its authorities. It has been run like this for years and worked completely fine. However after the upgrade, when abc's password expires, rather than prompting immediately after its successful login for a new password, it is now asking to change "root"'s password, and it really is changing root's password not abc's.

If I change abc's uid to another unique id, it will successfully says to change abc's password when prompted.

There are a lot of reasons why I cannot change abc's uid. So what I'm trying to find out is, why is this happening and how can I "fix" it? Is it really caused by the OS upgrade?

Solution 1

If two accounts have the same user ID, then by definition they are the same account. It is possible, but not recommended, to have more than one line in /etc/passwd (or other user database) with the same user ID; they are the same user, with different ways to log in.

You were using an unsupported feature. The risk of using an unsupported feature is that it sometimes breaks when the system is upgraded.

Expiring password is usually bad for security, as it causes users to choose weaker passwords or write them down on a post-it note stuck to the monitor. The only security benefit to expiring passwords is to eventually lock out abandonned accounts. Since the abc account is presumably one that you use as part of some kind of regular task, don't expire it.

You should probably change this setup, as it's fragile. What to change it do depends on what you use the abc account for (who has the password, in what circumstances it's used, what's abc's shell, is it present on multiple machines, …).

Solution 2

Most likely the system update introduced a script or other function related to password expiration which now looks up the username based on the UID, rather than gleaning the username from an environment variable or other source. As Gilles notes, having multiple usernames with same UID is fragile.

If you really can't move abc to another UID, then try looking for files/scripts associated with password expiration which may have been changed by the patch. For example, check /usr/sbin/userCommonTasks. It would be best if you could compare it to the pre-patch version. You might also check /etc/security/users. Perhaps moving abc's entry above root's might help.

Any fix is going to be hack, because having multiple usernames for one UID is kind of a hack, so ultimately you are just trading instabilities. But it should be possible to limp the system along if you can figure out what changed.

Comments

[Admin]

When logged in as abc, type the following commands and post the output: id whoami who am i

[Admin]

id uid=0(root) gid=0(system) groups=501(abc) whoami root who am i root pts/1 Oct 08 10:37 (xxx.xxx.xxx.xxx)

[Admin]

Does aix not support sudo like a proper unix should?

[matthew]

thanks for the advice, i wish i could change the password policy though... =(

[mattdm]

Password security against brute force attacks comes down to the number of attacks allowed against that password in its lifetime vs. the expected entropy in the password. If you have an infinite password lifetime, limitations to number of attempts and password strength have to be very high.

[Gilles 'SO- stop being evil']

@mattdm If the password lifetime was correlated to the expected cracking duration, it would be counted in minutes (most people's password choices) or in aeons (randomly-generated passwords). That is not at all why passwords are set to expire. It's mostly about a fuzzy feeling of doing something (no matter how useless and even counter-productive what you're doing is), and a little about deactivating abandoned accounts in the hope that you're doing it before the password is leaked.

[mattdm]

@Gilles: I agree that most people just pick a time limit for fuzzy reasons, but the theory is sound. Search "guessing entropy" for more.

[Gilles 'SO- stop being evil']

@mattdm The theory doesn't work because the estimates on the password entropy and on the attacker's computing power are so imprecise as to make any figure meaningless. Recommended reading: How does changing your password every 90 days increase security? (doesn't address guessing entropy, I don't remember seeing it discussed on Sec.SE).

[mattdm]

@Gilles — if the attacker has a list of hashes all bets are off because you can't limit guesses. But, in most cases, one can set policy like "5 failed guesses in 5 mins → 5 min wait". Since we have a general idea of the attack methods, guessing entropy can be estimated reasonably well. Then, take your estimated number of times to guess, divide by the number of guesses allowed, and there's your lifetime. If it comes up to short, inhibit guessing or increase strength reqs. Recommended reading: NIST SP800-63

[mattdm]

And, because of the things you've mentioned, 90 days probably is too short. Better to focus on the other things. (And better to use a smarter limiting method than the simple 5/5/5 example, like random but increasing slowing, but often software doesn't have that flexibility.)

[matthew]

thanks for the suggestions checked /usr/sbin/userCommonTasks nothing changed and tried moving abc above root in /etc/security/users but it didn't fix the problem

[Shadur]

Doesn't something like fail2ban solve that problem much more thoroughly?

[Gilles 'SO- stop being evil']

@Shadur What problem do you see here that fail2ban solves? It can only detect online cracking attempts, not offline, and it can't detect illegitimate use of the correct password.