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

Hello,

I think the idea of splitting CAP_WRITE into CAP_WRITE_DATA and
CAP_WRITE_CTRL makes sense, especially for cases where a process should be
able to exchange data but not transfer file descriptors.

From my perspective, the biggest concern is the capability change itself.
While source compatibility can largely be preserved by making CAP_WRITE an
alias for CAP_WRITE_DATA | CAP_WRITE_CTRL, there is still some potential
for compatibility issues with existing applications and binaries that rely
on the current semantics of CAP_WRITE.

Other than that, the use case seems reasonable, and being able to
explicitly prohibit SCM_RIGHTS on a socketpair could be a useful hardening
measure

Thanks,
Mariusz

On Tue, 2 Jun 2026 at 20:19, Kyle Evans <[email protected]> wrote:

> 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
>
>