[cap-talk] CapC? (was: execve() and CLOEXEC)

[David Hopwood]

Mark Seaborn wrote:
> I don't see this as different in principle to dealing with other
> unsafe interfaces.  For example, buffer overruns are caused both by
> specific library interfaces that are unsafe (i.e. difficult to use
> safely, or too easy to use unsafely) and by the fact that the C
> language is not memory-safe.  People have dealt with the buffer
> overrun problem at lots of different levels:
> 
[...]
>  * compiler + ABI changes (CCured, CapC)

I've never heard of CapC before, and it doesn't seem to be googleable.
Do you have a reference?

[...]
> I was going to cite Python's subprocess module as an example of a safe
> interface, but unfortunately when I checked I found its default is
> close_fds=False and not close_fds=True.  Part of the reason for that
> is that closing FDs can be slow for large FD tables
> (http://mail.python.org/pipermail/python-bugs-list/2007-February/037228.html),
> so some useful steps here would be to make sure there is a good way to
> close FDs in bulk efficiently and then to get Python's default
> changed.

Another problem with the Python implementation is that it is silently
unsafe if close() fails for a given fd. (According to
<http://www.opengroup.org/onlinepubs/000095399/functions/close.html>,
close() may fail if it is interrupted by a signal, or an I/O error
occurred. In either of these cases, the safe variant of execve should
also fail rather than ignoring the error.)

I entirely agree with your other points about CLOEXEC, execve, and
safe interfaces in general, BTW.

-- 
David Hopwood