Re: [capsicum] constructing a pure file descriptor from a capability

On 30 Nov 2012, at 22:54, Bill Harris wrote:

The details are in the Capsicum paper, but the principle is that capability-mode processes are denied unscoped access to global namespaces. We consider the TCP/IP address/port space to be a global namespace, and so connect()/bind() isn't allowed.

Ah, I think I see now. So I can write a program that calls cap_enter(), then creates a socket, and from that socket creates a capability with CAP_CONNECT. But the program still won't be able to use that capability to actually connect to a resource. OK, I think I get it.

The existence of CAP_CONNECT and CAP_BIND is currently a bit contradictory -- we allocated the bits as they were common file descriptor methods, but can't use them in that form. There are a number of such loose ends in the design -- Pawel's ongoing work as part of the Casper project will clean up several, although at the cost of some API disruption. (In particular, he has found he had to tweak some of the capability rights to permit constructs such as append-only capabilities on files -- which is very useful, but didn't quite fit our original model.) We're going to try to minimise disruption but may merge a few API changes to FreeBSD as we retained "experimental status" for Capsicum so can afford a bit of disruption. As there are some rather neat downstream Capsicum projects going on, I want to avoid too much disruption.


This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.