== _ls -l_ should show the presence of Linux capabilities

The other day I discovered that _/bin/ping_ is not setuid on Fedora 16
machines, in particular on my machines. But it still worked, and trying
to _strace_ it showed that somehow it still had some sort of setuid
permissions (because it didn't work any more, failing with permissions
errors).

(Ping normally needs to be setuid root in order to send raw ICMP
packets. You can question why this is a privileged operation and not
just another socket type, but that's the historical practice.)

On a regular Fedora 16 machine I might have said 'oh, SELinux' and left
it at that. But my machines have SELinux disabled, so something more was
clearly going on.  By prodding my fading memory and doing some searching
with _man -k_, I eventually found capabilities and especially _getcap_,
and it told me most of the answer:

> ((/bin/ping = cap_net_raw+ep))

Now here's the problem with this picture: ~~when I did an _ls -l_ of
ping, there was no sign that ping also had capabilities~~. In fact there
was no sign that ping had anything beyond normal permissions (and the
normal permissions were showing that it had no setuid).

I don't expect ls to have shown me the capabilities themselves. But
I've come to feel strongly that ~~_ls -l_ should always indicate if
a file has additional attributes of some sort~~. If a file has ACLs,
or capabilities, or even extended attributes, _ls -l_ should display
this. The reason is straightforward pragmatics; putting something in _ls
-l_ creates visibility, while having _ls -l_ silent makes it more or
less invisible.

(I was able to work out what was going on because I'm lucky and
reasonably well informed, but plenty of people are not.)

This is especially important on a modern Linux system because modern
Linux systems are already completely overgrown with [[special permission
systems Fedora16EnvironmentBits]] for having things magically happen or
magically acquire privileges (and most of these systems are effectively
invisible).  The last thing modern Linux needs is more invisible
permission systems; instead, programs such as ls should be working to
make them visible.

(All of this was sparked by [[a
https://twitter.com/aderixon/status/191543556081586176]]
[[Twitter
https://twitter.com/aderixon/status/191594871910436865]]
[[conversation
https://twitter.com/thatcks/status/191605198609854464]]
with [[@aderixon https://twitter.com/aderixon/]].)

=== Sidebar: why _ls -l_ having a marker would work

The goal of putting a marker in _ls -l_ output is twofold. If you
already know about capabilities it would tell you that the file has
them and you can get additional information with _getcap_ and so on. If
you don't know about capabilities, seeing something odd in the _ls -l_
output would at least tell you that there's something odd about the
file. You could then read the _ls_ manpage to find out what it means,
which would lead you to capabilities and _getcap_ and so on. Or to ACLs,
or to whatever else people want to add.

(Note that various versions of _ls_ (Linux's included) have already
fiddled around with the textual representation of permissions in _ls -l_
to add various things, so it's not as if the format of this is frozen in
stone beyond change.)