ls: fix capability coloring

Capability checking was incorrectly done on just the base name
rather than on the whole path.  Consequently there could be both
false positives and negatives when coloring files with capabilities.
Also capability checking was not done at all in certain cases for
non executable files.  Note passing absolute rather than relative
names to cap_get_file() reduces the has_capability() overhead
from around 33% to 30%.  I.E. ls --color is now around 3% faster.

* src/ls.c (struct fileinfo): Add a has_capability member.
(print_color_indicator): Refactor to pass just a fileinfo pointer
and a flag to say if we're dealing with a symlink target.
(print_name_with_quoting): Likewise.
(gobble_file): Set has_capability in the fileinfo struct.  Also do
a capability check even if executable coloring is disabled.
Ditto for SETUID and SETUID coloring.
Comment on how expensive has_capability() is.
(print_long_format): Adjust to refactored print_name_with_quoting.
(quote_name): Likewise.
(print_file_name_and_frills): Likewise.
* tests/ls/capability: Test the various false positive and negatives.
* THANKS: Add reporter (Ivan Labath).
* NEWS: Mention the fix.

1 files changed, 4 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index b13a5f21a..c9fe6caae 100644
--- a/NEWS
+++ b/NEWS
@@ -16,6 +16,10 @@ GNU coreutils NEWS                                    -*- outline -*-
   environment.  Likewise, printenv A=B silently ignores the invalid
   name.  [the bugs date back to the initial implementation]
 
+  ls --color now handles files with capabilities correctly.  Previously
+  files with capabilities were often not colored, and also sometimes, files
+  without capabilites were colored in error. [bug introduced in coreutils-7.0]
+
   md5sum now prints checksums atomically so that concurrent
   processes will not intersperse their output.
   This also affected sum, sha1sum, sha224sum, sha384sum and sha512sum.