Why are files that are not assigned to a user considered a security risk?

Question

From the Linux Bible, edition 9:

Files that are not assigned to any username are considered to be a security risk.

How is this possible and how could this be exploited?

Edit:My question isn't a duplicate of the mentioned question because my question is focused on the user creation process instead of focusing on the least privilege principle.

*"My question isn't a duplicate of the mentioned question because my question is focused on the user creation process instead of focusing on the least privilege principle."* - actually your question is not focused at all. Only the answer is focused on the user creation process but not your question. And, the arguments from the answer were actually made 5 years ago too. Therefore I see it still as a duplicate. — Steffen Ullrich, Jan 06 '18 at 20:17
@SteffenUllrich I agree it's a valid duplicate, but it took me a second to look past the somewhat ambiguous title. I reworded the duplicate target's title which hopefully makes that clearer to OP. — Arminius, Jan 07 '18 at 03:34
@AXANO Unless you really think there is major difference between the questions, I'd just go with the duplicate label (which doesn't make your question disappear and provides a useful pointer to future readers). — Arminius, Jan 07 '18 at 03:38

score 120 · Accepted Answer · edited Jan 05 '18 at 21:48

On a Linux system you can easily delete a user without having to delete any files owned by that user. Such a file will stay in place and the file owner's user ID (which is stored as an attribute of the inode) remains unchanged. This way a file can become effectively ownerless.

If you then later create a user with the same ID, the user will automatically become the owner of the previously orphaned files. That's how a new user may unintentionally (or with malicious intent) become the owner of files they shouldn't own, which is obviously bad for security.

Note that userdel has an extra switch to remove users along with their files, but it will only remove the files from some fixed locations, such as the home directory:

 -r, --remove
       Files in the user's home directory will be removed along with
       the home directory itself and the user's mail spool. Files
       located in other file systems will have to be searched for
       and deleted manually.

You may want to use find with the -nouser switch to discover files with a non-existent owner:

 -nouser
    No user corresponds to file's numeric user ID.

Here is a quick demo on Arch Linux.

Let's add a user alice and make her the owner of a file foo.

[root@box /]# useradd alice
[root@box /]# touch foo
[root@box /]# chown alice foo
[root@box /]# ls -l foo
-rw-r--r-- 1 alice root 0 Jan  5 02:59 foo

Now let's delete alice.

[root@box /]# userdel alice
[root@box /]# ls -l foo
-rw-r--r-- 1 1001 root 0 Jan  5 02:59 foo

ls can't determine the owner name and just displays the numeric owner ID 1001. Now let's add a new user bob.

[root@box /]# useradd bob
[root@box /]# ls -l foo
-rw-r--r-- 1 bob root 0 Jan  5 02:59 foo

Since bob has been assigned the next free user ID, he's now automatically the owner of the file.

Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/71283/discussion-on-answer-by-arminius-why-are-files-that-are-not-assigned-to-a-user-c). — Rory Alsop, Jan 06 '18 at 15:34

Why are files that are not assigned to a user considered a security risk?

From the Linux Bible, edition 9:

1 Answers1