On Linux, why can a regular user not hand one of their own files to another user with `chown`, while they can often change its group with `chgrp`?

## The asymmetry `chown` changes the owning user (and optionally the group); `chgrp` changes only the group. On Linux the two are governed by different rules: - **Changing the owner** requires privilege — root, or a process holding the capability that permits arbitrary ownership changes. The file's own owner cannot do it, and neither can the intended recipient. - **Changing the group** is allowed to the file's owner, provided the *target* group is one the owner belongs to (their effective GID or one of their supplementary groups). Anything else requires the same privilege as changing the owner. So a normal user can move a file between groups they are already in, and can never push a file into another user's name. ``` $ chgrp devs report.csv # ok if you own it and you are in devs $ chown deploy report.csv # chown: changing ownership: Operation not permitted ``` ## Why giving a file away is privileged POSIX makes this configurable and Linux chooses the restricted behaviour. The reasons are concrete: **Disk quotas.** Quota accounting is per owning UID. If any user could reassign ownership, filling your quota would be solved by handing files to someone else — while keeping full access to them through a permissive mode, since access is decided by the mode and your relationship to it, not by the fact that you created the file. Restricted chown is what makes quota accounting meaningful at all. **Attribution and repudiation.** Ownership is used across the system as evidence of who is responsible for a file. A user who could push files into another account could plant content and have it attributed to that account. **Escalation shapes.** Combined with other mechanisms, an unrestricted ability to hand out ownership creates awkward interactions — for example moving a file into an account whose home directory has different semantics, or handing over a file that a privileged process will later trust because of who owns it. The symmetrical case matters too: you also cannot *take* a file from another user. Ownership is not something the recipient can accept; only a privileged process can move it, which keeps the operation auditable in one place. ## The set-ID clearing rule When an unprivileged process changes a file's owner or group, the kernel clears the set-user-ID bit and, for group-executable files, the set-group-ID bit. This closes a gap: without it, a user could prepare a specially crafted executable and get its ownership changed, so that it later executed with someone else's identity. The clearing is automatic and silent, so a `chgrp` on an executable can quietly change its behaviour — which is a good reason to re-check modes after any bulk ownership change on a tree containing binaries. ## Practical usage `chown` accepts a combined form and can address the group alone: ``` chown app:app /srv/app/data # user and group chown :devs report.csv # group only, same effect as chgrp chown -R app:app /srv/app # recursive chown --reference=a b # copy owner/group from another file chown -h app:app link # act on a symlink itself, not its target ``` By default `chown` follows symbolic links and changes the target; `-h` changes the link. That distinction matters when recursing over a tree you did not create. A recursive ownership change is much safer than a recursive mode change — it is not destroying a per-file structure the way `chmod -R` does — but it is still worth knowing what is under the path, particularly whether anything there is deliberately owned by a different service account. ## Where it bites in production The recurring shape: a deployment or a restored backup leaves files owned by the wrong UID, and the service cannot write its own data directory. The fix is `chown -R` as root, not opening the mode up. Reaching for `chmod 777` to work around what is actually an ownership problem is the exact anti-pattern this question is testing for. A second shape appears when files move between systems: ownership is stored as a numeric UID and GID, not as a name. Copying a filesystem image, restoring an archive, or mounting a volume on a different host can leave files owned by a UID that maps to a different account — or to no account, in which case listings show a bare number. The bits did not change; the mapping did. ## What a strong answer includes Name the restriction and its reason (quota evasion and attribution), state the group rule precisely (owner, plus membership in the target group), mention that privilege is required for anything else, and add the set-ID clearing rule as the security detail that shows you know why the kernel does more than just update two numbers.