chownChange file owner and group
chown changes which user (and optionally which group) owns a file. Ownership decides which permission bits apply to a process, so a wrong owner is behind many 'Permission denied' errors from web servers, containers and services. Only root can give a file to another user.
chown [-R] [-h] [OWNER][:[GROUP]] FILE...The web app running as www-data fails to save uploaded files after someone copied the release as root.
sudoChanging a file's owner requires root (CAP_CHOWN), even for your own files.
chown resolves the names to numbers through NSS and calls fchownat() (lchown with -h) on each file, which stores the new UID and GID in the inode. The kernel only lets a process with CAP_CHOWN (root) change the owner: otherwise users could give files away to dodge disk quotas or plant setuid programs owned by others. A file's owner may change its group, but only to a group they belong to. When the owner or group of an executable changes, the kernel clears the setuid and setgid bits as a safety measure. With -R, chown walks the tree without following symlinks (-P is the default); without -R, a symlink given on the command line is dereferenced, so the target changes, not the link. The change updates the inode's ctime and takes effect for the next permission check; files already open stay open.
-RRecursiveUSER:GROUPSet both; USER: uses the user's login group; :GROUP only the group-hChange a symlink itself instead of its target-v / -cReport every file / only files that changed--from=OLDOnly change files currently owned by OLD (user, :group or both)--reference=FILECopy owner and group from another file-L / -H / -PWith -R: follow all / command-line / no symlinks (default -P)1000:1000Numeric IDs work too, even with no matching accountsudo chown -R www-data /var/wwwGives the web server write access to its own code: a compromised app can now rewrite itself.
Code owned by root (or a deploy user), read-only for www-data; chown only the upload/cache dirssudo chown -R kunal:kunal / home (a stray space)The space turns it into two paths: / and home. The whole system gets kunal as owner and breaks sudo, ssh and setuid binaries.
Type paths carefully; use --preserve-root (default for / itself) and check with echo firstExpecting chown to keep a binary setuidThe kernel clears setuid/setgid on any owner or group change of an executable.
chown first, then chmod u+s (if it really must be setuid)Matching container users by name ('chown appuser ...' on the host)The host's appuser may have a different UID from the container's. Only numbers matter.
Look up the container's UID (docker exec ... id) and chown -R UID:GIDTry these on a Linux machine of your own. Each task has a hint and a solution.
Create /tmp/shared.txt as yourself, then give it to root:root and show the result.
Change only the group of ~/app/README.md (or any file you own) to adm, without sudo if you're in adm.
Recursively give ~/data to UID 10001 and GID 10001, then list it with numeric IDs and change it back.
chownChange file owner and group
chown changes which user (and optionally which group) owns a file. Ownership decides which permission bits apply to a process, so a wrong owner is behind many 'Permission denied' errors from web servers, containers and services. Only root can give a file to another user.
chown [-R] [-h] [OWNER][:[GROUP]] FILE...The web app running as www-data fails to save uploaded files after someone copied the release as root.
sudoChanging a file's owner requires root (CAP_CHOWN), even for your own files.
chown resolves the names to numbers through NSS and calls fchownat() (lchown with -h) on each file, which stores the new UID and GID in the inode. The kernel only lets a process with CAP_CHOWN (root) change the owner: otherwise users could give files away to dodge disk quotas or plant setuid programs owned by others. A file's owner may change its group, but only to a group they belong to. When the owner or group of an executable changes, the kernel clears the setuid and setgid bits as a safety measure. With -R, chown walks the tree without following symlinks (-P is the default); without -R, a symlink given on the command line is dereferenced, so the target changes, not the link. The change updates the inode's ctime and takes effect for the next permission check; files already open stay open.
-RRecursiveUSER:GROUPSet both; USER: uses the user's login group; :GROUP only the group-hChange a symlink itself instead of its target-v / -cReport every file / only files that changed--from=OLDOnly change files currently owned by OLD (user, :group or both)--reference=FILECopy owner and group from another file-L / -H / -PWith -R: follow all / command-line / no symlinks (default -P)1000:1000Numeric IDs work too, even with no matching accountsudo chown -R www-data /var/wwwGives the web server write access to its own code: a compromised app can now rewrite itself.
Code owned by root (or a deploy user), read-only for www-data; chown only the upload/cache dirssudo chown -R kunal:kunal / home (a stray space)The space turns it into two paths: / and home. The whole system gets kunal as owner and breaks sudo, ssh and setuid binaries.
Type paths carefully; use --preserve-root (default for / itself) and check with echo firstExpecting chown to keep a binary setuidThe kernel clears setuid/setgid on any owner or group change of an executable.
chown first, then chmod u+s (if it really must be setuid)Matching container users by name ('chown appuser ...' on the host)The host's appuser may have a different UID from the container's. Only numbers matter.
Look up the container's UID (docker exec ... id) and chown -R UID:GIDTry these on a Linux machine of your own. Each task has a hint and a solution.
Create /tmp/shared.txt as yourself, then give it to root:root and show the result.
Change only the group of ~/app/README.md (or any file you own) to adm, without sudo if you're in adm.
Recursively give ~/data to UID 10001 and GID 10001, then list it with numeric IDs and change it back.