My manager instructed me to delete a user, then the next day asked me to add the user back (office politics).
I did a simple userdel to remove the user, but did not delete his home directory. The next day I added the user back with useradd, and set the password to what it was previously. I added him to the same group as before also.
1.) Now the user is complaining that when he logs in he gets the standard colored directories (blue on black background), and says that the previous admin had set his color to white only. Where is this info kept? I would assume in .bashrc or .bash_profile or something similar, but those files are still in his old home directory, and I don't think they were overwritten when I recreated the user.
2.) We have a database user on the system, let's call him 'database'. All users log in as themselves, su or sudo to root, and then su to the database user in order to access database functions. However, this user apparently had the previous admin set up something for him where he could just log in as himself and immediately access all database functionality. I figured the user's new account just needed to be added to the database user's group, but that didn't do it.

Addn'l info:
This is a Red Hat Linux server.
This user was not in /etc/sudoers.

Any ideas?

Edit: The lesson I learned from this experience is that user accounts should be disabled for one week, prior to being deleted. At least then you have the chance to set things back to previous without any hassle.

Did you check the permissions on the files in the old home directory? Is it possible that userdel does a chown when the user is deleted. Also, when you recreated the user. did that user get the same ID number that they had before you deleted the user? As far as I know, the security goes by user number, not user name.

adding to whats said already

Probably a 'ls' alias in ~/.bashrc or ~/.bash_profile with the "--color=none" option or LS_COLORS env var (see 'man dircolors').


Why not sudo to the db user immediately, I wonder?..


If he's an unprivileged user and w/o sudoers entry then another way to elevate his privileges could have been him being in the wheel group. If you have a backup you could check /etc/groups and PAM.

This had occurred to me, I am going to try to determine what his old userid number was, and edit the /etc/passwd file to set it back to that (if I can find it).

unSpawn, good suggestions, thanks!

Hey There,


Definitely. His old uid should have been the owner of his original directory after you deleted him.

Also, if he had customizations in his .bashrc, etc, they may have been overwritten when you did the useradd if you specified the directory, since it may have copied back default profile files if you have that set up.

In the future, in your case, just disable users when they leave - since your boss might be bringing them back next week

For this guy, just tell him he's gonna have to wait. He went to the back of the line when he walked

just kidding (kind of

Best wishes,

Mie

I think that there is an option in the ls command to display UIDs as well (or in place of) user names.

Wouldn't be easier to just do a (recursive) chown on the old directory so the user becomes the owner of that directory.

You might want to find any files in the old directory which are owned by the current UID of the user before running a chown and decide if you want the newer file or (hopefully) a backup containing the older file. (Since the new UID would, presumably, not have permission to modify any files owned by the old UID, the old ones should still be around somewhere.

My recollection is the the new user GUI gives you an option to set the UID of the new user, so -- if you go the GUI route -- you might consider deleting the nw user (again) and recreating that user with the old UID. Unless, of course, that UID has been assigned to some other user. (That possibility is one of many reasons why just editing the passwd file is problematic.). If you do edit passwd, be aware that there are also "shadow" copies of that file, and your edit may be ignored in the next reboot.

You do have backups????

Ok, the answer ended up being that the user previously had the same UID as the database user. This allowed him to get database access without getting root access.

Also, I retrieved his old .bashrc and .bash_profile from a backup tarball, and updated the default ones that had overwritten his old ones.

In .bashrc, the following line was added:
alias ls="ls --color=no"

Additionally, in .bash_profile, the following lines were added:
alias l="ls -l"
set -o vi

Thanks for your help guys.

Hey There,

Did you mean same GID or same actual user id? God bless him if he can get away with it, but I think that's a security concern and might cause some issues for him with the OS (like if you run pwchk or pwconv, you might see errors and how does the OS know to take him to his home directory rather than the DB user's?)

Or, maybe I'm reading this wrong and he basically "is" the database user account and his access was just revoked by changing the password or something.

Sorry if it reads like a dumb question Just curious.

, Mike