POSIX ACLs: Give Specific Users File Access Without Changing Ownership

The problem: one group is not enough

You have a file on a shared Linux server. The finance team needs to read it, one developer needs to edit it, and everyone else should be locked out. Traditional Unix permissions let you assign one owner, one group, and access for everyone else. You cannot add a second group or an individual user without making that user a member of the file's group, which often means granting more access than intended.

What POSIX ACLs add

POSIX Access Control Lists (ACLs) extend the familiar owner/group/others model by attaching named entries to a file's metadata. An ACL can list specific users, called named-user entries, and specific groups, called named-group entries, with their own read, write, or execute rights. The existing permission bits still exist, but ACL entries are checked when the kernel decides whether to allow access.

Check that your filesystem supports ACLs

Before using ACLs, confirm the filesystem is mounted with ACL support. Run this in a terminal on the host where the file lives:

mount | grep 'on /srv '

Look for the acl mount option in the output. If it is missing, remount with acl or update /etc/fstab and remount. You can also inspect a specific filesystem with tune2fs -l /dev/sda1 | grep acl, replacing /dev/sda1 with your device. You need root or sudo permissions to remount or run tune2fs.

Worked example: grant edit access to one user

Suppose /srv/project/report.csv is owned by eng:eng with mode 640. The owner and group can read and write; others have no access. You want user deploy to read and write the file without adding deploy to the eng group.

Run as the file owner or root:

setfacl -m u:deploy:rw /srv/project/report.csv

Verify with:

getfacl /srv/project/report.csv

Expect to see a line such as user:deploy:rw- in the listing, alongside the standard owner, group, and mask entries. The mask entry limits the maximum permissions that named users and named groups can receive; if the mask is r--, a rw- ACL entry for deploy effectively grants only read access.

To remove that specific entry later:

setfacl -x u:deploy /srv/project/report.csv

To remove all ACL entries and return to traditional permissions only:

setfacl -b /srv/project/report.csv

Default ACLs for new files in a directory

If you want every new file created inside /srv/project/drafts/ to inherit access for deploy, set a default ACL on the directory:

setfacl -d -m u:deploy:rwx /srv/project/drafts/

New files created in that directory should then carry the inherited ACL entry. Confirm with getfacl on a newly created file.

Trade-offs and limitations

• Not every tool respects ACLs. Some backup scripts, legacy editors, or simple permission checkers inspect only the traditional mode bits and may report incorrect access.
• The ACL mask can silently reduce permissions. Always check the mask line in getfacl output.
• ACLs are not universal. Filesystems such as FAT32 and some older BSD variants do not support them.
• Each ACL entry consumes inode metadata. On filesystems with millions of small files, many entries can increase metadata overhead.

Practical verification and closing

Test on a non-production copy first. After applying an ACL, log in as a user who is not listed in the ACL and confirm access is denied. Then log in as the intended user and confirm the expected read or write succeeds. If access behaves unexpectedly, inspect the mask and the mount options before escalating privileges or changing ownership.

POSIX ACLs are useful when traditional Unix groups are too coarse, but they work best when your team knows to check getfacl alongside ls -l.