CoursesLinux essentialsPermissions & ownership

Ownership: users & groups on files

chown, chgrp, and who can do what.

Beginner10 min · lesson 15 of 25

Permissions decide what the owner, group, and others may do — ownership decides who those are. Every file has a user owner and a group owner, and which category your permissions fall into depends on your identity: if you own the file you get the owner bits, if you are in its group you get the group bits, otherwise you get the others bits. So the same file gives different access to different people, entirely based on ownership.

terminal
$ ls -l app.log
-rw-r----- 1 appuser appgroup 2048 Jul 3 app.log
# appuser (owner) can read/write; members of appgroup can read; nobody else can touch it
$ chown appuser app.log # change the owning user (usually needs root)
$ chgrp appgroup app.log # change the owning group
$ chown appuser:appgroup app.log # both at once

Groups are how you share access

Groups are the mechanism for letting several users share access without giving everyone access. Put the people who need a set of files into a group, own the files by that group, and grant group permissions — now exactly those users get in, and adding or removing someone is a group-membership change, not a permission rewrite on every file. This is least privilege in practice on a single host: grant through group membership, not by widening others.

terminal
$ groups deploy # which groups is this user in?
deploy sudo docker
$ sudo chgrp devs /srv/app && sudo chmod 2770 /srv/app
# /srv/app now: the devs group can read/write; others get nothing (the 2 = SGID, next lesson)

chown usually needs root — and that matters

A normal user cannot give away a file to another user (chown to someone else) — only root can, because otherwise you could plant a file and blame someone else, or dodge disk quotas. You can change a file’s group to a group you belong to, but changing ownership is a privileged operation. This restriction is a small but real security property: file ownership is a trustworthy record of who created something.

Wrong ownership breaks services quietly
A frequent operational bug: a service runs as its own user (say www-data) but a file it needs is owned by root and not readable by others — the service fails with a permission error that looks mysterious. When something "cannot open" a file it should, check ownership and permissions first with ls -l. And never "fix" it with chmod 777; grant access through correct ownership and group membership instead.