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

Sure, no objection- that was my first inclination, but I renamed it to COMPAT at the last minute to match the COMPAT_FREEBSD* nomenclature.  If there aren't any complaints about the notion within the next week or so, I'll go ahead and hack something up.

On 6/3/26 09:17, Mariusz Zaborski wrote:
> Actually I would feel safer with CAP_WRITE_LEGACY.
> 
> On Wed, 3 Jun 2026 at 16:15, Kyle Evans <[email protected] <mailto:[email protected]>> wrote:
> 
>     On 6/3/26 03:04, Mariusz Zaborski wrote:
>      > 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.
>      >
> 
>     My alternative proposal would be that we slice off two entirely new bits in index 1 and still make `CAP_WRITE` an alias, but rename the current assignment to `CAP_WRITE_COMPAT`.  We don't have any precedent for it, but I'd then handle translation at the cap_rights_*(2) border and unset the new `CAP_WRITE` if `CAP_WRITE_COMPAT` is unset when limiting, and unset `CAP_WRITE_LEGACY` if *either* of the new `CAP_WRITE_*` rights are missing.
> 
>     I don't know how I feel about it, but I bet it would work.
> 
>      > 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] <mailto:[email protected]> <mailto:[email protected] <mailto:[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
>      >
>