"ls -l" shows wrong permissions for group when ACLs set
 

LFS permissions are set as:
-rw-r-----. 1 root testgroup 6 Jul 28 10:55 testfile

Then,
setfacl -m u:bob:rw testfile

And ls -l yields:
-rw-rw----+ 1 root testgroup 6 Jul 28 10:55 testfile

Notice the change in the group write permission. However, getfacl says:
user::rw-
user:bob:rw-
group::r--
mask::rw-
other::---

And, in testing, members of testgroup can read the file but not write to it. In other words, getfacl shows the true permissions while ls -l is wrong.

It seems to be related to the mask. If I change the mask, to "r" then the group shows only "r" permissions as well. But then Bob's effective permissions are also only "r". I know the mask overrides the group in the negative direction but it's not additive - it's the MAX permissions on a file.

Why is ls -l not giving the correct information?

This is CentOS 7 on an XFS formatted drive.

Bump
 

Still trying to figure this one out. I've googled more and still coming up empty for answers. Anyone have an idea what might be happening?

man 5 acl, specifically, the "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" section.
On Slackware it doesn't seem possible to create an acl without a mask entry (not with setfacl at any rate), so that second part may not be a practical consideration.

Basically,
If the group permissions show 'rwx' then you might have any of r,w, or x permissions granted from the acl, but equally, you might not.
If the group permissions show 'r-x' then you definitely won't have 'w', but may have one, or both of the other two; though again, you might not.

If you want to know for certain, you're going to have to run getfacl.


ACLs are ugly, which is why most people avoid them like the plague.

Hope that helps.

Thanks GazL. So you're basically saying that, if we use ACLs, we shouldn't trust ls. To me, that's a bug that the coreutils group should address. But, ok, if that's the answer for now then that's the answer.

BTW, I like ACLs. I avoid them if possible just because they are complex and adding needless complexity is never a good idea. But I like that they're there and, when I do use them, they're powerful.

Yes, ACL's are useful when you need additional flexibility, but what you have to remember is that ACLs were essentially an after thought/extension to UNIX so they don't integrate completely with the original UNIX owner/group/other model, and that's why tools like ls don't cater for them. A switch on ls that shows 'effective rights' for the calling user probably wouldn't be a bad idea, though it'd probably slow ls down quite a lot.