Red Hat Bugzilla – Bug 430779
/bin/ls incorrectly shows '+' for files without an ACL
Last modified: 2008-01-31 11:50:53 EST
Description of problem: /bin/ls is outputting a '+' indicating an ACL is present for all files, even those (the vast majority) that don't have them. Version-Release number of selected component (if applicable): coreutils-6.10-2.fc9.x86_64 How reproducible: % /bin/ls -l /etc/passwd -rw-r--r--+ 1 root root 2087 2008-01-27 01:20 /etc/passwd Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Thanks for report, I expected something like that... That's because of the change in coreutils-6.10 ... /* For long listings, true if the file has an access control list, or an SELinux security context. */ bool have_acl; So files have have_acl boolean set because of security context. Will check how to handle this, because upstream version implemented SELinux changes unlike with RedHat patch, therefore such behaviours could occur now(and have to be fixed before F9)
Did the author of that comment realize that on an SELinux system, *all* files have a context, even if it's "unlabeled_t"?
I totally agree... but unlabeled_t is handled different way (and will not show with show with that +) . Even if I agree that scontext could be considered as ACL in some kind of meaning, I would like to separate character for only selinux context and for real access control list. Do you like that kind of solution? I mean for example asterisk for ACL set and + for only !unlabeled security context?
I think you need to keep '+' for "ACL set", because there's a lot of installations where that's the way it works, and sysadmins and users expect that "if it has a +, you need to run getfacl or something to look at the ACL". I suppose putting a '*' for SELinux would be OK, except that it's going to generate a flurry of "Why does every file have a *" questions - a support nightmare (not necessarily for you, but I know *I* will get a note from *every single person* at my site that installs F9 :) Perhaps the *right* solution is "output a * if you find an *anomalous* SELinux context - for instance, if there's a context but SELinux isn't active, or if we find a file with a broken/illegal context, or maybe unlabeled_t if running MLS or other policy where it shouldn't happen"?
Ok, you are right... but I have to keep it as close as possible to upstream code. So I'll do following: 1)For clasic long format : + for ACL , * for scontext 2)For scontext long format: + for ACL, nothing for scontext (because scontext is displayed as string in this case) + maybe some documentation on man pages (but I'm not sure about that, because I think there is no documentation about other things in long format)
Maybe we can just toss the indication for SELinux context, since there's already a -Z flag?
Maybe that is better way than in my #5 comment. Fedora/RHEL coreutils already differ from upstream in selinux options of ls and we have more options how to get SELinux context informations. So we could use coreutils 6.9 handling style with + only for ACL (at least for F9 ...)
Just want to mention upstream URL of GIT commit with ls SELinux options implementation - they count SELinux security_context as some form of ACL (as I said in comment #3) - but as you said, on SELinux system it will be confusing to have + everywhere: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3ea540c7570a76bf72ae697c4040e77dad5bea6d
Built as coreutils-6.10-4.fc9 , closing RAWHIDE