Why did a new user inherit files from a deleted user

administrationusers

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?

Best Answer

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

Related Solutions

I’ve just “mv”ed a 49GB directory to a bad file path, is it possible to restore the original state of the files

When moving files between filesystems, mv doesn't delete a file before it's finished copying it, and it processes files sequentially (I initially said it copies then deletes each file in turn, but that's not guaranteed — at least GNU mv copies then deletes each command-line argument in turn, and POSIX specifies this behaviour). So you should have at most one incomplete file in the target directory, and the original will still be in the source directory.

To move things back, add the -i flag so mv doesn't overwrite anything:

sudo mv -i ~/my_data_on_60GB_partition/* /media/admin/my_data/

(assuming you don't have any hidden files to restore from ~/my_data_on_60GB_partition/), or better yet (given that, as you discovered, you could have many files waiting to be deleted), add the -n flag so mv doesn't overwrite anything but doesn't ask you about it:

sudo mv -n ~/my_data_on_60GB_partition/* /media/admin/my_data/

You could also add the -v flag to see what's being done.

With any POSIX-compliant mv, the original directory structure should still be intact, so alternatively you could check that — and simply delete /media/admin/my_data... (In the general case though, I think the mv -n variant is the safe approach — it handles all forms of mv, including e.g. mv /media/admin/my_data/* my_data_on_60GB_partition/.)

You'll probably need to restore some permissions; you can do that en masse using chown and chmod, or restore them from backups using getfacl and setfacl (thanks to Sato Katsura for the reminder).

Best Answer

Related Solutions

I’ve just “mv”ed a 49GB directory to a bad file path, is it possible to restore the original state of the files

Related Question