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 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 Twitter conversation with @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.)