Rénich's Blog

Using ACLs on Fedora Like a Pro (Because sudo is for Noobs)

Hero image for Using ACLs on Fedora Like a Pro (Because sudo is for Noobs)

January 31, 2026

Hola! You know how sometimes you have a service user (like a bot or a daemon) that needs to access your files, but you feel dirty giving it sudo access? I mean, la neta, giving root permissions just to read a config file is like killing a fly with a bazooka. It's overkill, dangerous, and frankly, lazy.

Today I had to set up my AI assistant, Clawdbot, to access some files in my home directory. Instead of doing the usual chmod 777 (please, don't ever do that, por favor) or messing with groups that never seem to work right, I used Access Control Lists (ACLs). It's the chingón way to handle permissions.

What the Hell are ACLs?

Standard Linux permissions (rwx) are great for simple stuff: Owner, Group, and Others. But life isn't that simple. sometimes you want to give User A read access to User B's folder without adding them to a group or opening the folder to the whole world.

ACLs allow you to define fine-grained permissions for specific users or groups on specific files and directories. It's like having a bouncer who knows exactly who is on the VIP list.

Note

Fedora comes with ACL support enabled by default on most file systems (ext4, xfs, btrfs). You're good to go out of the box.

The Magic Commands: getfacl and setfacl

Definitions:
getfacl:
Shows the current Access Control List of a file or directory. Think of it as ls -l on steroids.
setfacl:
Sets the ACLs. This is where the magic happens.

Real World Example: The Clawdbot Scenario

Here's the situation: I have my user renich and a service user intro (which runs Clawdbot).

  • Problem: I want renich (me) to have full access to intro's home directory so I can fix config files without logging in as the bot.
  • Constraint: I don't want to use root all the time.

Step 1: Check Current Permissions

First, let's see what's going on with intro's home directory.

getfacl /home/intro

Output might look like this:

# file: home/intro
# owner: intro
# group: intro
user::rwx
group::---
other::---

See that? Only intro has access. If I try to ls /home/intro as renich, I'll get a "Permission denied". Qué gacho.

Step 2: Grant Access with setfacl

Now, let's give renich full control (read, write, execute) over that directory.

sudo setfacl -m u:renich:rwx /home/intro

Breakdown:

  • -m: Modify the ACL.
  • u:renich:rwx: Give u**ser **renich r**ead, **w**rite, and **e(x)ecute permissions.
  • /home/intro: The target directory.

Tip

If you want this to apply to all new files created inside that directory automatically, use the default flag -d. Example: sudo setfacl -d -m u:renich:rwx /home/intro

Step 3: Verify It Worked

Run getfacl again to verify.

getfacl /home/intro

Result:

# file: home/intro
# owner: intro
# group: intro
user::rwx
user:renich:rwx    <-- Look at that beauty!
group::---
mask::rwx
other::---

Now renich can browse, edit, and delete files in /home/intro as if they were his own. Suave.

Why This is Better than Groups

You might be asking, "Why not just add renich to the intro group?"

  1. Granularity: ACLs let you give access to just one specific file if you want.
  2. No Relogin Required: Group changes often require logging out and back in. ACLs apply immediately.
  3. Cleaner: You don't end up with a mess of groups for every little permission variation.

Conclusion

ACLs are one of those tools that separate the pros from the amateurs. They give you precise control over your system's security without resorting to the blunt hammer of root or chmod 777.

Next time you need to share files between users, don't be a n00b. Use setfacl.

Warning

Don't go crazy and ACL everything. It can get confusing if you overuse it. Use it when standard permissions fall short.