Ownership: users & groups on files
chown, chgrp, and who can do what.
A file on a shared Linux machine is like a folder in an office filing cabinet. Someone's name is written on the tab, and the whole folder is filed under a department. Linux does exactly this with every single file. Each one records one person who owns it, and one group it belongs to. Those two labels decide, before anything else, who is allowed to read it, change it, or run it.
Under the hood the machine doesn't store your name at all. It stores numbers. Every user has a uid (user ID, a number the kernel uses to tell people apart), and every group has a gid (group ID). The kernel (the core part of the operating system that talks to the hardware and enforces the rules) only ever thinks in these numbers. The friendly names you read on screen, like appuser or sudo, are looked up from the files /etc/passwd and /etc/group for your benefit.
Reading the name tags
The ls -l command (list, in long format) prints both labels on every line.
Read that line left to right. The -rw-r----- block is the permissions. After the link count (1) come the two labels that matter here: appuser is the user owner, and appgroup is the group owner. So on this log file, appuser can read and write it, anyone in appgroup can read it, and everyone else gets nothing.
That permission block is really three small blocks stitched together: three letters for the owner, three for the group, and three for everyone else. Ownership is the thing that decides which of the three blocks the system reads for you.
Which rules apply to you
A club with three guest lists works the way Linux does. The bouncer checks the first list your name could be on, applies that list, and stops. Linux checks in a fixed order. Are you the owner? If yes, you get the owner's rules and the check ends right there. Not the owner? Are you in the file's group? If yes, group rules, and it ends there. Neither of those? You fall through to the 'others' rules.
The part that trips people up is that it stops at the first match. You can own a file, be a member of its group, and still be blocked, because the owner block is read-only while the group block would have let you write. The more generous rule further down never gets looked at.
r-- cannot write the file even if the group or others have w. If you find yourself locked out of your own file, check the owner bits, not the group ones. As the owner you can always run chmod to hand yourself access back, which is the usual fix.Changing the group with chgrp
Two commands move these labels around. chgrp (change group) sets the group owner. chown (change owner) sets the user owner, and can set both at once. Start with chgrp, because it is the one a normal user is allowed to use. First, though, see which groups you are actually in. The id command spells it out.
That user's primary group is deploy, and they also belong to sudo and docker. Membership is the catch: you can only hand a file to a group you belong to. Try to give it to a group you are not in, and the kernel refuses.
Point it at a group you are in, and it works quietly. In Linux, no output means it worked. Verify by listing the file afterward.
Changing the owner with chown
Giving a file to a different person is a bigger deal, so Linux guards it more tightly. Handing over your own house key is fine; forcing your key onto someone else is not a thing you get to do. Changing a file's user owner to another account needs root (the superuser, the all-powerful administrator account). A normal user cannot do it, not even to files they own.
With root, through sudo (run this one command as the superuser), it goes through. You can set the user and the group in a single step by joining them with a colon.
Why lock this down to root? Two reasons, both about trust. If anyone could reassign ownership, you could drop an incriminating file into someone else's home directory and stamp their name on it. And on systems with disk quotas (per-user limits on how much space each account may use), you could dodge your limit by pushing your files onto another user's tab. Because only root can give a file away, the owner field is a record you can mostly trust. It usually points to whoever made the file.
Groups are how you share without oversharing
Say five engineers need to work on the same directory and nobody else should get in. You could widen the 'others' permissions, but then every account on the box gets in too, which is the opposite of what you want. The clean answer is a shared group. This is least privilege on a single host: you grant access through membership, not by loosening the rules for the whole world.
Make a group, put those five people in it, set the directory's group owner to it, and grant the group read and write. Now access is a property of group membership. Adding a sixth engineer is one command, not a permission rewrite across hundreds of files. Removing someone who leaves is just as quick.
That s sitting where the group's x would normally be is SGID (set-group-ID, the leading 2 in 2770). It makes new files created inside the directory inherit the devs group automatically, which is the subject of the next lesson. One more thing about the usermod -aG devs alice line: adding someone to a group does not take effect in sessions they already have open. Their running shells and processes keep the old group list until they log out and back in. If a teammate says you added them to the group but they still cannot get in, that is almost always the reason.
What ownership tells a defender
Ownership does two jobs at once. It is a record you read after something goes wrong, and it is a place attackers try to game, so a security engineer checks it constantly. After a break-in, the owner and group on files are some of the first things worth looking at.
Files that belong to no known user are a red flag. They turn up when an account was deleted but its files were left behind, or when an attacker unpacked an archive that carried raw numbers instead of names. You can hunt for them directly.
That file is owned by uid 1504 with no matching name, sitting in a web directory. On a normal server that is the kind of thing you want to explain before you sleep. The bare number, shown instead of a friendly name, is the tell that no such user exists on this machine.
Those raw numbers matter in one more place a DevSecOps engineer lives in every day: containers. Inside a container, ownership is still nothing but uid and gid numbers, and those numbers do not respect the container boundary. A file written by uid 1000 inside a container shows up as uid 1000 on the host, which might be a completely different named person, or nobody at all. When a mounted volume gives you 'permission denied', the fix is almost always to line up the numeric owner on both sides, not to loosen the permissions.
The most common ownership bug in production is not an attack at all. It is a service that cannot read its own files. Watch it happen with systemctl (the command that drives systemd, the program that starts and supervises services on a modern Linux).
The service runs as its own user, myapp, but look at who owns the file it needs.
The rw------- says only the owner may read it, and the owner is root, not myapp. The service matches the 'others' class, which grants nothing, so it fails with a message that looks mysterious until you check ownership. The right fix is to give the file to the account that needs it, which is exactly the sudo chown myapp:myapp from earlier.
chmod 777 (read, write, and execute for everyone). Do not. That hands your private key to every user and every process on the box, including whatever an attacker is already running. Grant access by setting the correct owner or group instead, and keep a secret readable only by the one account that genuinely needs it.Try this
Work through “What ownership tells a defender” yourself on a sandbox you can throw away, following the commands above in order. Then break one step deliberately and re-run, so you have seen the failure before it finds you.
Takeaway
The trap worth remembering here: owning a file does not guarantee you can write it. Check that on your own systems before you need to, because it is cheaper to find on a quiet afternoon than during an incident.