Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 2 down vote favorite

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?

share|improve this question
When logged in as abc, type the following commands and post the output: id whoami who am i – Seth Noble Oct 5 '12 at 16:29
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) – matthew Oct 8 '12 at 7:10

3 Answers

up vote 0 down vote

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

share|improve this answer
thanks for the advice, i wish i could change the password policy though... =( – matthew Oct 8 '12 at 7:59
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. – mattdm♦ Oct 8 '12 at 16:04
@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. – Gilles Oct 8 '12 at 18:15
@Gilles: I agree that most people just pick a time limit for fuzzy reasons, but the theory is sound. Search "guessing entropy" for more. – mattdm♦ Oct 8 '12 at 18:42
@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). – Gilles Oct 8 '12 at 19:30
show 2 more comments
up vote 0 down vote

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.

share|improve this answer
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 – matthew Oct 10 '12 at 3:35
up vote 0 down vote

Maybe if you change root's UID from 0 to anything else?

share|improve this answer
4  
That will probably entirely break the system. – mattdm♦ Nov 2 '12 at 14:49

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer: please explain why you're recommending it as a solution. Answers that don't explain anything will be deleted. See Good Subjective, Bad Subjective for more information.

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.