Blogging after the pub is a mixed blessing. A time when I want to
write about things! But! A time when I should be sleeping.
Last week I wrote nearly 2000 boring words about keyboards and stayed
up till nearly 4am. A stupid amount of effort for something no-one
should ever have to care about.
Feh! what about something to expand the mind rather than dull it?
Years and years ago I read practically everything on
http://erights.org - the website for the E programming language -
which is a great exposition of how capabilities are the
way to handle access control.
I was reminded of these awesome ideas this evening when talking to
Colin Watson about how he is
One of the great E papers is Capability Myths
Demolished. It's extremely
readable, has brilliant diagrams, and really, it's the whole point of
this blog post.
Go and read it: http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
One of the key terms it introduces is "ambient authority". This is
what you have when you are able to find a thing and do something to
it, without being given a capability to do so.
In POSIX terms, file descriptors are capabilities, and file names are
ambient authority. A capability-style POSIX would, amongst other
things, eliminate the current root directory and the current working
directory, and limit applications to
openat() with relative paths.
Practical applications of capabilities to existing systems usually
require intensive "taming" of the APIs to eliminate ambient authority
- see for example
CaPerl and CaJa.
From the programming point of view (rather than the larger systems
point of view) eliminating ambient authority is basically eliminating
From the hipster web devops point of view, the "12 factor
application" idea of storing
configuration in the environment is basically a technique for reducing
Another useful idea in the Capability Myths
Demolished paper is
capability attenuation: if you don't entirely trust someone, don't
give them the true capabilty, give them a capability on a proxy. The
proxy can then restrict or revoke access to the true object, according
to whatever rules you want.
(userv proxies POSIX
file descriptors rather than passing them as-is, to avoid transmitting
unwanted capabilities - it always gives you a pipe, not a socket, nor
a device, etc.)
It is too late and my mind is too dull now to do justice to these
ideas, so go and read their paper instead of my witterings.