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):
% /bin/ls -l /etc/passwd
-rw-r--r--+ 1 root root 2087 2008-01-27 01:20 /etc/passwd
Steps to Reproduce:
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. */
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
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:
Built as coreutils-6.10-4.fc9 , closing RAWHIDE