"ls -l" shows wrong permissions for group when ACLs set
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"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.
Last edited by davemha; 07-28-2015 at 11:09 AM.
Reason: Add distro info
man 5 acl, specifically, the "CORRESPONDENCE BETWEEN ACL ENTRIES AND FILE PERMISSION BITS" section.
Quote:
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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.