Take the 2-minute tour ×
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.

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?

share|improve this question

2 Answers 2

up vote 40 down vote accepted

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

share|improve this answer
2  
...this seems like a terrible security flaw. Is there any way to work around it? –  BlueRaja - Danny Pflughoeft Aug 26 '13 at 9: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 Aug 26 '13 at 9:59
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 Aug 26 '13 at 13:24
1  
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 Aug 26 '13 at 13:33
5  
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

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

share|improve this answer

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.