rights(4) split? CAP_WRITE -> CAP_WRITE_DATA + CAP_WRITE_CTRL

Hi,

I'm looking at an application where it would be useful to be able to construct a socketpair(2) that can't be used to send fds over, out of an abundance of caution.  The application in prison0 is effectively a broker between two jails that it hands each an end of the socketpair, then steps out of the way -- I don't see a reason to leave it capable of carrying SCM_RIGHTS.

I'd like to propose splitting CAP_WRITE into CAP_WRITE_DATA and CAP_WRITE_CTRL, with CAP_WRITE being an alias for DATA|CTRL.  The caveat is that I don't know if being able to revoke data but not control messages is really feasible or useful, off-hand.

In any event, my plan would be to use the last bit available in rights idx 0 for the CTRL right, rename the current CAP_WRITE to CAP_WRITE_DATA, and create a new CAP_WRITE name for the two combined.   There's some chance for breakage in applications that haven't been rebuilt with the new definition of CAP_WRITE, but I suspect most of them aren't attempting to send control messages.  The in-kernel users of CAP_WRITE look like they could mostly be scoped down to CAP_WRITE_DATA specifically, though maybe that gets a little awkward in `flags_to_rights` mapping of O_WRONLY/O_RDWR.

Thoughts? Terrible idea?

Thanks,

Kyle Evans