26

So I had to do an exercise in a book as homework. First you had to create a user like:

useradd -c "Steven Baxter" -s "/bin/sh" sbaxter

Then you had to add some files to the /home/sbaxter directory:

touch /home/sbaxter/ some.txt new.txt files.txt

Then you had to remove the sbaxter user and create a new user named mjane. To my suprise when I ran find /home/ -user mjane, the new user mjane now owned all of sbaxter's old files, what happened?

strugee
  • 14,723
  • 17
  • 73
  • 119
John
  • 418
  • 3
  • 9

2 Answers2

43

The devil is in the details, in the useradd man page (you can see that by issuing man 8 useradd):

   -u, --uid UID
       The numerical value of the user's ID. This value must be unique,
       unless the -o option is used. The value must be non-negative. The
       default is to use the smallest ID value greater than or equal to
       UID_MIN and greater than every other user.

So it will default to using the smallest uid unused, that is larger than other users, in the password file. Seeing as deleting sbaxter removed him from the passwd file, his uid is "free" and gets assigned to mjane (as the uid useradd picks is the same for both users at the time the useradd command was used).

Files on disk only store uid, and NOT the user name translation (as this translation is defined in the password file). You can confirm that by issuing ls -ln to see what uid ownership files have.

I would actually recommend you disable rather than delete accounts. Locking accounts on most Linux distributions can be achieved with usermod -L -e today <username>, which locks the password and sets the account to expire today (you can see the expiry date of an account with chage -l).

Drav Sloan
  • 14,145
  • 4
  • 45
  • 43
  • +1 great answer, thank you for the clarification, I didn't know the the file only kept track of the uid and not the actual username. Makes a lot of sense, thanks! – John Aug 26 '13 at 03:16
  • 3
    ...this seems like a terrible security flaw. Is there any way to work around it? – BlueRaja - Danny Pflughoeft Aug 26 '13 at 09:30
  • 6
    @BlueRaja-DannyPflughoeft This isn't a security flaw: users are identified by their user ID, not by their user name. When you delete an account, you must remove all of its files (i.e. all the files owned by this user ID, not just the user's home directory). This is part of the normal procedure to remove an account. – Gilles 'SO- stop being evil' Aug 26 '13 at 09:59
  • @Gilles: good answer, but also keep some of those files (according to local laws), ie for example the mbox could have to be saved for a while (thus, just chown (and chmod) those files to something other users can't access, or make an archive of them (with protected uid and rights) and delete the originals) – Olivier Dulac Aug 26 '13 at 13:15
  • 2
    @OlivierDulac *That* is called a backup. Alternatively, lock but do not remove the account as long as you need to keep its data. After all, if you need to keep the data, then the account is still needed. – Gilles 'SO- stop being evil' Aug 26 '13 at 13:24
  • 1
    Locking accounts on most Linux distributions can be achieved with `usermod -L -e today `, which locks the password and sets the account to expire today (you can see the expiry date of an account with `chage -l`). – Drav Sloan Aug 26 '13 at 13:33
  • 6
    It is a security flaw, by todays standards. As the example shows, this means that you cannot associate humans with files. Sure, humans may be strongly associated with accounts, but the association human<->account<->file breaks down due to UID recycling. Then again, Unix never had great security in this respect (`root` could fake almost anything). You need audit trails for that. – MSalters Aug 26 '13 at 14:01
  • Isn't it just the `useradd` software that's like that and couldn't a request for modification be submitted to _shadow-tools_ to have an option which takes into account existing data in /home for instance? Or is it just you must know the best practices before doing account administration? –  Aug 26 '13 at 22:23
  • @MSalters I don't think it's that big of a problem, seeing as it is something that can be covered by policy rather than any sort of exploit. When you orphan files like that what do you expect to happen? It's like use-after-free in programming - undefined behavior results. Standard procedure is to delete files associated with an account at the time of account deletion. If those files cannot be deleted, ownership should be transferred to a different account. If that's still not feasible then obviously the account still needs to exist and should not be deleted. – jw013 Aug 27 '13 at 20:44
  • @jw013: "When you orphan files". Stop. That's already the problem right there. "Standard procedure" is a tacit admission of failure. We have computers to do standard procedures. Of course, part of that is done by `userdel`, but it acknowledges its limitations: "You should manually check all file systems to ensure that no files remain owned by this user.". Welcome to the 21st century :| – MSalters Aug 27 '13 at 22:55
  • @MSalters I don't think the need for policy enforcement is a problem unless I am misunderstanding you. Even in the real world, when a person suddenly dies without a will or close living relations, his possessions become "orphaned" and some policy somewhere dictates what to do with it (donate it? burn it? auction it?). The situation in the question is like a landlord simply giving the dead person's apartment to some new renter, leaving new guy to inherit all the deceased person's stuff. Policies exist to prevent this sort of chaos (e.g. delete a user's `$HOME` and other files before `userdel`). – jw013 Aug 29 '13 at 18:43
14

The UID of the deleted user was reused by the new user, and filesystems use a UID for ownership, not a username.

Ignacio Vazquez-Abrams
  • 44,857
  • 7
  • 93
  • 100