Re: https://reviews.freebsd.org/D57255 - migrating cut and rev

--0000000000005abad306536ddfb9
Content-Type: text/plain; charset="UTF-8"

Ah and BTW I have tested this changes as part of the review.

On Thu, 4 Jun 2026 at 15:50, Mariusz Zaborski <[email protected]> wrote:

> Hello,
>
> Of course, I'm not the best person to advocate for it :)
>
> There are, of course, hidden implementation costs. A lot more happens
> under the hood
> during the process, such as spawning Casper, communication with service
> and other
> related operations. There has always seen a dilemma around whether we
> actually
> need this and what the tangible benefits are.
>
> On one hand, I would love to see all tools sandboxed. On the other hand,
> if we're talking about
> tools that are not setuid/setgid and are potentially as simple as cut(1)
> or rev(1), it introduces
> significant overhead that may outweigh the security benefits.
> We had the same dilemma with cat(1). We have an implementation of a secure
> cat(1),
> but it is disabled in the default installation.
>
> I still see opportunities to improve fileargs. For example, if the file
> descriptor limit is lower
> than the fileargs cache size, then instead of spawning Casper, we could
> simply cache the file
> descriptors. I think that would address many of the performance concerns
> while preserving
> most of the benefits.
>
> If there are many opposing views, I would still suggest committing this
> change with the
> feature disabled by default and revisiting it once fileargs improvements
> are available.
>
> Thanks,
> Mariusz
>
> On Thu, 4 Jun 2026 at 04:06, Adrian Chadd <[email protected]> wrote:
>
>> hi!
>>
>> Nick has posted a review to capsicumize the cut and rev tools.
>> I'd like to see more base system utilities using our local security
>> things for, well, security things.
>>
>> The diff is up here in review - https://reviews.freebsd.org/D57255
>>
>> Does anyone have any strong opinion about this? I don't know anything
>> about the implementation details here nor the cost (or not) of
>> migrating our base tools to actually use capabilities, and I'd like to
>> get some eyeballs / opinions on those who may.
>>
>> Thanks!
>>
>>
>> -adrian
>>
>>

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

<div dir=3D"ltr">Ah and BTW I have tested this changes as part of the revie=
w.</div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt=
r" class=3D"gmail_attr">On Thu, 4 Jun 2026 at 15:50, Mariusz Zaborski &lt;<=
a href=3D"mailto:[email protected]">[email protected]</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-left:1ex"><div dir=3D"ltr"><=
div><div><div><div><div><div>Hello,<p><span>Of course, I&#39;m not the best=
 person to advocate for it :)</span></p><p><span>There are, of course, hidd=
en implementation costs. A lot more happens under the hood<br>during the pr=
ocess, such as spawning Casper, communication with service and other<br>rel=
ated operations. There has always seen a dilemma around whether we actually=
<br>need this and what the tangible benefits are.</span></p><p><span>On one=
 hand, I would love to see all tools sandboxed. On the other hand, if we&#3=
9;re talking about<br>tools that are not setuid/setgid and are potentially =
as simple as=C2=A0</span>cut(1) or rev(1),<span>=C2=A0it introduces<br>sign=
ificant overhead that may outweigh the security benefits.</span></p>We had =
the same dilemma with cat(1). We have an implementation of a secure cat(1),=
</div><div>but it is disabled in the default installation.<br><br>I still s=
ee opportunities to improve fileargs. For example, if the file descriptor l=
imit is lower</div><div>than the fileargs cache size, then instead of spawn=
ing Casper, we could simply cache the file</div><div>descriptors. I think t=
hat would address many of the performance concerns while preserving</div><d=
iv>most of the benefits.<br><br></div>If there are many opposing views, I w=
ould still suggest committing this change with the</div><div>feature disabl=
ed by default and revisiting it once fileargs improvements are available.</=
div></div></div><br></div>Thanks,<br></div>Mariusz</div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Jun 2026 at 04:=
06, Adrian Chadd &lt;<a href=3D"mailto:[email protected]" target=3D"_blank=
">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">hi!<br>
<br>
Nick has posted a review to capsicumize the cut and rev tools.<br>
I&#39;d like to see more base system utilities using our local security<br>
things for, well, security things.<br>
<br>
The diff is up here in review - <a href=3D"https://reviews.freebsd.org/D572=
55" rel=3D"noreferrer" target=3D"_blank">https://reviews.freebsd.org/D57255=
</a><br>
<br>
Does anyone have any strong opinion about this? I don&#39;t know anything<b=
r>
about the implementation details here nor the cost (or not) of<br>
migrating our base tools to actually use capabilities, and I&#39;d like to<=
br>
get some eyeballs / opinions on those who may.<br>
<br>
Thanks!<br>
<br>
<br>
-adrian<br>
<br>
</blockquote></div>
</blockquote></div>

--0000000000005abad306536ddfb9--