Bug 430779 - /bin/ls incorrectly shows '+' for files without an ACL
Summary: /bin/ls incorrectly shows '+' for files without an ACL
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-01-29 18:29 UTC by Valdis Kletnieks
Modified: 2008-01-31 16:50 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-01-31 16:50:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Valdis Kletnieks 2008-01-29 18:29:55 UTC
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:

Comment 1 Ondrej Vasik 2008-01-29 18:39:10 UTC
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)

Comment 2 Valdis Kletnieks 2008-01-30 00:03:59 UTC
Did the author of that comment realize that on an SELinux system, *all* files
have a context, even if it's "unlabeled_t"?  

Comment 3 Ondrej Vasik 2008-01-30 09:47:15 UTC
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?

Comment 4 Valdis Kletnieks 2008-01-30 16:59:55 UTC
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"?

Comment 5 Ondrej Vasik 2008-01-30 18:51:45 UTC
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)

Comment 6 Valdis Kletnieks 2008-01-30 18:53:17 UTC
Maybe we can just toss the indication for SELinux context, since there's already
a -Z flag?

Comment 7 Ondrej Vasik 2008-01-30 20:05:30 UTC
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 ...) 

Comment 8 Ondrej Vasik 2008-01-31 11:38:12 UTC
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

Comment 9 Ondrej Vasik 2008-01-31 16:50:53 UTC
Built as coreutils-6.10-4.fc9 , closing RAWHIDE


Note You need to log in before you can comment on or make changes to this bug.