Wandering Thoughts archives

What do Unix errno values mean?

Here's a philosophical question: what do Unix errno values mean?

One possible meaning is that they are hints about why your system call failed. Another possible meaning is that they specify what went wrong; in the extreme, a system call can only fail for certain specific reasons, each of which is associated with a specific errno value.

Errno as a hint is essentially the traditional Unix view. V7 Unix didn't even document specific error returns for system calls, and Bell Labs took it to the logical extreme in Plan 9, where system calls return error strings instead of fixed error numbers.

(There are reasons to use fixed error numbers instead of strings even if errno is just a hint; it helps internationalization, for example.)

Errno as a specification and contract is in full flower in Unix specifications like the System V Interface Definition, POSIX, and the Single Unix Specification. Their documentation is full of promises that system calls must return specific errno values in specific circumstances (and sometimes, must never return other values; what you are supposed to do if the system call fails for some other reason is not specified).

I'd say that the specification writers created this situation, but I don't think that's entirely fair: in a sense, the situation is the fault of BSD Unix's support for non-blocking sockets. Various important bits of state information are communicated via errno values, and this can only work if those errno values are a contract instead of a hint.

In practice, you are much safer considering errno as a hint (outside of a few errno values when working with non-blocking sockets), because this is the reality on at least one popular Unix. (I suspect that it's the reality on most popular Unixes, but I haven't checked.)

Extra security systems for Unix should be explicit, not implicit

I'm no fan of SELinux, but in stumbling over it a few times I've come to some theories about why I don't think it works. One of them, perhaps the most important one, is this:

Extra Unix security stuff needs to be simple and explicit.

Extra Unix security stuff needs to be explicit because the effective alternative is invisibility, since Unix already has one security system and most people aren't going to do very well remembering a second invisible one.

(A great deal of SELinux is implicit, in file contexts and so on, so when something goes wrong it is a mysterious failure with an invisible cause. The very existence of setroubleshoot, whose purpose is to try to make SELinux less invisible, shows the problem acutely.)

One simple change that would make SELinux a lot less invisible would be to give it its own errno value, with an accompanying useful error string. Then programs that fail because of some SELinux ailment might at least print something that points people to the cause, instead of a 'permission failed' message that just leaves the poor sysadmin frustrated because as far as they can see, the permissions are fine.

(Similar logic applies to remote filesystems; if the client thinks that everything should be OK but the server disagrees, I think you probably want to return a different errno value to the program. I'm aware that no one agrees with me here.)

A corollary to this is that I think process confinement should be an extra mechanism and be explicit; one mechanism would be that you just run a program like su to start programs in the confined setting of your choice. Then you could at least see this in places like startup scripts, and you could try it out by hand, and so on.

(I don't have a good answer for how confined processes should show up in ps output. Perhaps every confinement mode should have a UID and login assigned to it, although then you'd want the kernel to either automatically confine processes running as that UID or refuse to allow you to become that UID outside of the confinement system, so you can never have a process running as that UID that is not confined.)