Why is it possible to assign non-existent users as file owners via the "chown" command?
To give you an example
sudo chown 03:03 ./test/f2
ls -l
-rw-r--r-- 1 3 sys 0 nov 7 17:45 f2
sudo chown 1555552:03 ./test/f5
ls -l
-rw-r--r-- 1 3 19508 0 nov 7 18:04 f5
You may find an explanation in the article How To chown to a non-existent user on Ubuntu?
(The bold highlight is by me.)
In conclusion, while chown requires a valid user or group name to change ownership, you can still assign ownership to a non-existent user by using their numerical UID and GID. This can be particularly useful when dealing with files and directories that were created on another system, or when preparing a system for a new user.
What you have discovered is actually a feature of chown intended to
solve the problem of preparing a file for use on another system or
for a future user.
Linux is not designed to babysit you, it is designed to obey you. Well, as a regular user you are limited in what you can do and it makes sense; but to run chown you need to be root anyway and Linux is certainly designed to obey root.
With this philosophy we don't need any reason for chown to allow assigning a "non-existent" user as the owner. It's the other way around: we would need a good reason for chown to deny this.
For comparison, here are few examples where root cannot (or "cannot") do something:
/dev/mem is not as accessible as it used to be. There is a good reason:
With the exception of the BIOS area, there's just no valid app that uses
/dev/memon actual memory. Other popular users of/dev/memare rootkits and the like.
To circumvent this one needs to compile the kernel with the right option. This cannot be done spontaneously, on the fly, within a minute. This means that accessing /dev/mem is something root truly cannot do on demand. Still, planning in advance, compiling and starting a reconfigured kernel in advance allows root to do this.
Root "cannot" access FUSE of another user, unless FUSE is started with allow_root. This is an alleged limitation, because root can always become the right user with sudo or su.
Root "cannot" use GNU rm to remove /. Again, not really a limitation: there is --no-preserve-root option that makes rm -rf / work. The point is to prevent mishaps like fat-fingered Enter after / in rm -rf /'some dir', or like rm -rf /"$var" when $var is empty when you don't expect it.
Even root "cannot" use some functionalities of hdparm. The tool will ask the user to supply the --yes-i-know-what-i-am-doing or --please-destroy-my-drive flag if the chosen functionality is dangerous. Note man 8 hdparm yells DO NOT USE!, DON'T EVEN THINK ABOUT USING IT or something similar next to several options, still these options are supported and with determination root can use them. An excellent application of the philosophy.
As you can see, only the first example is a real limitation. Now, is there a reason to limit root's usage of chown (really or allegedly)? Let's see…
Filesystems store ownership as IDs, i.e. as numbers, they don't care if these numbers correspond to names. Assigning a user ID not associated with any name cannot break the filesystem itself. There is no problem on the filesystem level.
A problem will arise on the OS level if a crucial file (e.g. /etc/sudoers) gets chown-ed to a wrong user. A wrong user ID is wrong, regardless if it's an "existing" (named) user or not. It's not a matter of "existing user" vs "non-existing user", it's "the right user" vs "anything else".
So if we wanted chown to impose some restrictions in order to prevent us from breaking things, it should know what files to protect and how. Simply not allowing "non-existent" users makes little to no sense, because you can equally easily break things by assigning a named (yet wrong) user to a crucial file.
Allowing "non-existent" users is actually useful, other answers give valid examples and I'm not going to repeat them. Even if we knew no scenario where it was useful, in my opinion it should still be allowed and supported. Years ago I moved from Windows to Linux and one of the reasons was Windows too often "thought it knew better" (note: I don't know if new versions of Windows still do this).
Historically(**) after you have logged into a UNIX system you are just a number (your UID) and you have a sets of groups (which are also just numbers GID's).
** - There are newer permissions systems with ACL's
Behind the scenes most security checks are performed using the numbers instead of your user or group name. From this viewpoint there is no such thing as a "non-existent" user or group, in both cases they are just "unnamed" users/groups - i.e user 5042 exists, it just doesn't have a name.
However even on a single machine there can be different mappings from Names to IDs, for example:
Therefore it makes sense for commands to allow the raw IDs to be entered to allow for use cases where the mappings don't exist (in the current context).
