In Unix-like systems with ACL support, there's an intricate relationship between traditional permission bits and access control lists. When you execute a chmod operation on group permissions, it directly affects the ACL mask due to historical compatibility and design decisions.

$ touch testfile
$ setfacl -m u:testuser:rwx testfile
$ getfacl testfile
# file: testfile
# owner: user
# group: group
user::rw-
user:testuser:rwx
group::r--
mask::rwx
other::r--

The mask in ACL systems serves as an upper limit for permissions granted to named users and groups. When you modify group permissions via chmod, the system assumes you want to maintain compatibility with non-ACL aware applications.

This design accomplishes three main objectives:

• Backward compatibility with legacy systems
• Preventing permission escalation through ACLs
• Maintaining a single source of truth for maximum permissions

If you need to modify group permissions without affecting the ACL mask, consider:

# First set the desired mask
$ setfacl -m m::rwx targetfile

# Then modify group permissions through ACL
$ setfacl -m g:mygroup:rw- targetfile

The effective permissions are calculated as:

effective_perms = requested_perms & mask & group_perms

This is why modifying group permissions affects the final outcome - it's part of the logical AND operation that determines access.

Different Unix-like systems handle this slightly differently:

For fine-grained control without this interaction:

# Using extended attributes directly
$ setfattr -n system.posix_acl_access -v $(getfacl -e file | setfacl --set-file=-) file

The key insight is that ACLs were designed to extend traditional Unix permissions, not replace them. This integration explains why chmod operations affect ACL components.

When working with file permissions on Unix-like systems, there's an important interaction between traditional permission bits and Access Control Lists (ACLs) that many developers find surprising. The key observation is this: modifying group permissions with chmod directly affects the ACL mask.

Let's examine this behavior with concrete examples:

# Create a test file and set ACL
$ touch testfile
$ setfacl -m u:developer:rwx testfile
$ getfacl testfile
# file: testfile
# owner: devuser
# group: devgroup
user::rw-
user:developer:rwx
group::r--
mask::rwx
other::r--

# Now modify group permissions
$ chmod g+w testfile
$ getfacl testfile
# file: testfile
# owner: devuser
# group: devgroup
user::rw-
user:developer:rwx        #effective:rwx
group::r--                #effective:r--
mask::rwx
other::r--

The interaction stems from historical compatibility requirements. Traditional Unix permissions didn't have ACLs, so when ACLs were introduced, they needed to maintain backward compatibility with existing tools like chmod. The ACL mask serves as an upper limit of permissions that can be granted to named users and groups.

If you need to modify group permissions without affecting the ACL mask, you have several options:

# Method 1: Use setfacl to modify the mask afterward
$ chmod g+w file
$ setfacl -m m::rwx file

# Method 2: Use the --mask option with setfacl
$ setfacl --mask -m g::rw file

When designing permission schemes:

• Always check ACLs after running chmod commands
• Consider using setfacl exclusively for files with complex permission needs
• Document your permission strategy for future maintenance

The ACL mask acts as a filter for named user and group entries. The actual permissions (shown as #effective in getfacl output) are the intersection of the requested permissions and the mask.

$ setfacl -m u:qa_engineer:rwx,u:manager:r--,g:auditors:r-x testfile
$ chmod g-w testfile
$ getfacl testfile
# The mask will now reflect the group write permission removal
# affecting all ACL entries

Different filesystems handle this slightly differently:

• ext4: Fully supports POSIX ACLs with this behavior
• XFS: Similar behavior but with better performance for large ACLs
• ZFS: Has its own ACL implementation with different characteristics

For systems where this behavior is problematic:

# Consider using extended attributes directly
$ attr -s permissions -V "complex_rules" file

# Or implement a wrapper script that handles both chmod and setfacl
# operations atomically