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?
Best Answer
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, …).