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

--00000000000002207e065354e3ab
Content-Type: text/plain; charset="UTF-8"

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

--00000000000002207e065354e3ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello,<br><br>I think the idea of splitting CAP_=
WRITE into CAP_WRITE_DATA and CAP_WRITE_CTRL makes sense, especially for ca=
ses where a process should be able to exchange data but not transfer file d=
escriptors.<br><br>From my perspective, the biggest concern is the capabili=
ty change itself. While source compatibility can largely be preserved by ma=
king CAP_WRITE an alias for CAP_WRITE_DATA | CAP_WRITE_CTRL, there is still=
 some potential for compatibility issues with existing applications and bin=
aries that rely on the current semantics of CAP_WRITE.<br><br>Other than th=
at, the use case seems reasonable, and being able to explicitly prohibit SC=
M_RIGHTS on a socketpair could be a useful hardening measure</div><p><span>=
Thanks,<br>Mariusz</span></p></div></div><br><div class=3D"gmail_quote gmai=
l_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 2 Jun 2026=
 at 20:19, Kyle Evans &lt;<a href=3D"mailto:[email protected]">kevans@free=
bsd.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">Hi,<br>
<br>
I&#39;m looking at an application where it would be useful to be able to co=
nstruct a socketpair(2) that can&#39;t be used to send fds over, out of an =
abundance of caution.=C2=A0 The application in prison0 is effectively a bro=
ker between two jails that it hands each an end of the socketpair, then ste=
ps out of the way -- I don&#39;t see a reason to leave it capable of carryi=
ng SCM_RIGHTS.<br>
<br>
I&#39;d like to propose splitting CAP_WRITE into CAP_WRITE_DATA and CAP_WRI=
TE_CTRL, with CAP_WRITE being an alias for DATA|CTRL.=C2=A0 The caveat is t=
hat I don&#39;t know if being able to revoke data but not control messages =
is really feasible or useful, off-hand.<br>
<br>
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 c=
reate a new CAP_WRITE name for the two combined.=C2=A0 =C2=A0There&#39;s so=
me chance for breakage in applications that haven&#39;t been rebuilt with t=
he new definition of CAP_WRITE, but I suspect most of them aren&#39;t attem=
pting to send control messages.=C2=A0 The in-kernel users of CAP_WRITE look=
 like they could mostly be scoped down to CAP_WRITE_DATA specifically, thou=
gh maybe that gets a little awkward in `flags_to_rights` mapping of O_WRONL=
Y/O_RDWR.<br>
<br>
Thoughts? Terrible idea?<br>
<br>
Thanks,<br>
<br>
Kyle Evans<br>
<br>
</blockquote></div>

--00000000000002207e065354e3ab--