How to Set ACL Inheritance for New Files in Linux Web Directories (Gentoo/Ext4)


2 views

When migrating from AFS to a standard Linux filesystem with POSIX ACLs, one critical difference surfaces: default ACL inheritance behavior. In our Gentoo Linux environment with ext4 filesystem (acl flag enabled), newly created files weren't automatically inheriting parent directory permissions - a requirement for our multi-user web development workflow where both developers and www-data need access.

Linux implements two types of ACLs:

# Display ACLs of a directory
getfacl /var/www/html/project
  • Access ACL: The actual permissions (what you see with getfacl)
  • Default ACL: The inheritance template (appears when using getfacl -d)

For new files to inherit permissions automatically:

# First set the directory's access ACL
setfacl -Rm u:developer:rwx,u:www-data:r-x /var/www/html/project

# Then establish inheritance rules
setfacl -Rm d:u:developer:rwx,d:u:www-data:r-x /var/www/html/project

Create a test file and check permissions:

touch /var/www/html/project/test.html
getfacl test.html

# Expected output:
# user:developer:rw-
# user:www-data:r--

Add these to your filesystem mount options in /etc/fstab:

UUID=xxxx /var/www ext4 acl,user_xattr,defaults 0 2
  1. UMASK conflicts: Ensure umask doesn't override ACLs (022 is recommended)
  2. Filesystem support: Verify mount | grep acl shows ACLs enabled
  3. Recursive application: Use setfacl -R for existing directories

Sometimes you need execute permissions for directories but not files:

setfacl -Rm d:u:www-data:r-x,d:mask:r-x /var/www/html/project
setfacl -Rm d:u:www-data:r--,d:mask:r-- /var/www/html/project --set-file=<(getfacl /var/www/html/project | sed 's/d:.:x//')

When migrating web infrastructure from AFS to standard Linux filesystems with POSIX ACLs, administrators often encounter permission inheritance issues. In our case, we needed to maintain the AFS-like behavior where new files automatically inherit parent directory permissions - crucial for collaborative web development where multiple users and www-data need specific access rights.

By default, Linux filesystems with ACL support don't automatically propagate directory ACLs to new files. This creates problems when:

  • Developers create new PHP/HTML files in web directories
  • CMS systems generate new assets
  • Multiple users collaborate on web projects

The solution lies in setting default ACLs using the setfacl command. Here's how it works:

# Set default ACL while preserving existing permissions
setfacl -d -m u:www-data:rwX,u:developer1:rwX,g:webteam:rwX /path/to/webdir

# Verify the settings
getfacl /path/to/webdir

The magic happens with the -d flag (default) and X (capital X) which applies execute permission only to directories.

For a typical web project with multiple contributors:

# 1. Set the base directory permissions
chmod 2770 /var/www/project-x
chown :webteam /var/www/project-x

# 2. Apply inheritable ACLs
setfacl -Rm d:u:www-data:r-x,d:u:alice:rwx,d:u:bob:rwx /var/www/project-x
setfacl -Rm u:www-data:r-x,u:alice:rwx,u:bob:rwx /var/www/project-x

Create a test environment:

mkdir -p /tmp/acl_test
setfacl -d -m u:www-data:rwX,u:$USER:rwX /tmp/acl_test
touch /tmp/acl_test/newfile.txt
getfacl /tmp/acl_test/newfile.txt

The output should show inherited permissions from the parent directory.

For Gentoo systems, consider adding these commands to your deployment scripts or system configuration:

# /etc/local.d/acl-setup.start
#!/bin/sh
setfacl -d -m u:www-data:rwX /var/www
setfacl -R -m u:www-data:rX /var/www

Remember to make the script executable:

chmod +x /etc/local.d/acl-setup.start
  • ACLs not working? Ensure your filesystem is mounted with acl option in /etc/fstab
  • Execute bits missing? Use capital X instead of lowercase x in your ACL definitions
  • No inheritance? Verify you used the -d flag when setting ACLs

While implementing ACL inheritance:

  1. Audit existing permissions before migration
  2. Test with non-privileged users before production deployment
  3. Consider using group permissions where possible instead of individual user ACLs