Years ago I mentioned in passing that SELinux should have its own errno value. Today I feel like running down both the technical details of how I think it should work and why it makes sense.

First, I don't think this should be specific to just SELinux. The reality is that Unix kernels are increasingly growing security restrictions over and above standard Unix permissions, all of which suffer from the same visibility problems that SELinux has. Rather than give them all different errno values, I think that there should be a single errno value, call it ESECURITY, which means 'this action was denied due to some additional security policy'.

(It would thus trigger for things like Ubuntu's additional security hardening.)

The advantage of such an errno is that it tells everyone where to look, or at least that there is no point in looking at standard Unix permissions. You know right away that something odd is going on and won't wind up spending a bunch of time looking at file permissions, UIDs, and so on and going 'this should work, why on earth is it failing?'. Today the last is quite common with SELinux (and other such things) and is one large reason they are so frustrating for many people.

The Unix tradition (in general) is to add new errno values for new forms of system call failure; this is the tradition that gave us, for example, ESTALE. 'This operation was denied because of an additional security policy' is clearly a new form of system call failure and so it makes complete sense for it to have a new errno value (and more than one if it becomes necessary). Returning EPERM is not good enough because in reality almost everyone today who sees EPERM assumes that the cause is normal Unix permissions (as shown by all the stories of people who did not think to look at SELinux until much, much later).

(Some people will argue that adding a new errno return is not standards compliant. Fortunately for us, Linux has never promised to be fully POSIX compliant; Linus himself has said in the past that Linux sticks to POSIX only when POSIX makes sense. Refusing to add new errno values for new forms of failure is neither sensible nor useful.)