3

I just deleted a user with "userdel", without deleting its home dir. Right after the deletion, I created a new user, with its own home dir.

What striked me as odd, was that the new user gets the UID of the deleted user (the last UID, incremented by 1).

Consequently, the new user also has ownership and full permissions on the files of the deleted user!

Is this normal behaviour? Is there a best practice on how to prevent this, short of specifying a UID each time when creating a new user?

(Tested on Linux Mint 17 and verified on OpenSuse 13.1)

7
  • 2
    Don't delete old accounts. Just remove their password so they can't login.
    – Barmar
    Sep 1, 2014 at 20:11
  • @Barmar That sounds quite wasteful, for machines that go through a lot of users, say in a university... Though now that I think about it, every university system I know appends a number when students have the same initials and never reuses previous numbers, even after the original initials graduate. Is such administrative wisdom documented somewhere?
    – Anko
    Sep 1, 2014 at 20:18
  • 1
    Best practices for sites with high turnover like universities is probably different. But if you're going to delete the account, you should wipe all their files off the system (not just remove their home directory, they could have files elsewhere).
    – Barmar
    Sep 1, 2014 at 20:20
  • Best practise will vary from site to site. Our policy is to move user home directories from the default home directory to a directory that only root has access to. We then run a usermod -c to change the GECOS field to begin with the word DEPARTED. We then lock the account with passwd -l. It avoids UID reuse.
    – Warwick
    Sep 2, 2014 at 0:11
  • 2
    Best practice is to keep track of usernames and uids in a common database rather than letting useradd pick the uids based on the lowest available number in some arbitrary (distro-dependent) range. In NFS v3 environments, it's important for a given person to have the same uid on every client. When the user departs, the files either get removed or chowned to someone who wants them. Sep 2, 2014 at 0:28

2 Answers 2

3

If you delete the user account, then the user no longer exists. It's perfectly normal that the user ID then gets reused: there is nothing to distinguish this user ID from any other unused user ID.

If the account still owns files, the account still exists, so you need to keep it around. Don't delete the entry in the user database, mark it as disabled. On Linux:

usermod --expiredate 1 --lock --shell /dev/null

When you're sure you want to delete the account, first make sure that you've deleted every file that belongs to it (find -user may help). Then delete the account with userdel.

If the user has a dedicated group, remember to delete it as well.

3
  • 1
    I tested the reuse of UIDs. The UID of the new user is apparently always 1 higher than the current highest UID, even if there are "holes" due to deleted users. So the problem I mentioned in my original post above applies only to the deletion of the user with the current highest UID. (tested on Linux Mint 17)
    – twan163
    Sep 3, 2014 at 6:44
  • 1
    @twan163 Indeed, this is documented behavior for useradd in the Linux shadow suite. Anyway, the point remains that if you stop marking a user ID as being in use, it can be reused. If you want to prevent reuse, the way to do that is to leave the entry in the database. Sep 3, 2014 at 6:50
  • Of course, I failed to see that one coming! :)
    – twan163
    Sep 3, 2014 at 6:52
0

unix doesn't work with user/group, it work with uid/gid, you change uid/gid, please fix new uid/gui with your home directory: for example:

chown 1002.1002 yourdir -R

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .