Linux – Who can change ACL permissions

You'll notice the "effective" comment that getfacl is throwing out at you. The issue is that permissions are calculating so that "app" isn't getting the write bit set. That's happening because the mask on the file is set to read-only. The mask is used to limit the amount of permissions that could possibly be given out on a particular file or directory.

An example of why you would want this behavior would be like if you knew the file could legitimately need different users/groups to have access to it but for some reason things were getting complicated with permissions and you wanted a way to say "Whatever the other default permissions are set to, whatever their group memberships are, or whatever recursive setfacl gets executed later on, DEFINITELY DON'T GIVE THIS OUT!" The owning user has a special status in the POSIX world, it has rights other users don't have, like the ability to be non-root and change permissions on a file and have its rights not be limited by the mask (which would be pointless anyways because of the first privilege the system gives them). This is why they still get rwx even though the mask is restricted.

To answer your specific question though: add the write bit to the mask on the file and try again as the john user.

here is a command line version of the above explanation, take note of how the "effective" rights change when all I modify is the mask.

It doesn't make sense if the unix file permissions disagree to the acl entry and vice versa. Accordingly, the manual page (acl(5)) says what you ask for:

CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS

The permissions defined by ACLs are a superset of the permissions specified by the file permission bits.

There is a correspondence between the file owner, group, and other permissions and specific ACL entries: the owner permissions correspond to the permissions of the ACL_USER_OBJ entry. If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Otherwise, if the ACL has no ACL_MASK entry, the group permissions correspond to the permissions of the ACL_GROUP_OBJ entry. The other permissions correspond to the permissions of the ACL_OTHER_OBJ entry.

The file owner, group, and other permissions always match the permissions of the corresponding ACL entry. Modification of the file permission bits results in the modification of the associated ACL entries, and modification of these ACL entries results in the modification of the file permission bits.

Addendum in response to the discussion:

What is the reason for coupling ACL mask and file group permissions? What logic does lay behind it?

A good explanation is here. In essence the mask is an

[...] upper bound of the permissions that any entry in the group class will grant.

This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.

In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.

This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions. The mapping of the group class permissions is no longer constant.