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

--000000000000a8acd606536dd38b
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div><div><div><div><div><div>Hello,<p class=3D"gmail-isSe=
lectedEnd"><span>Of course, I&#39;m not the best person to advocate for it =
:)</span></p><p class=3D"gmail-isSelectedEnd"><span>There are, of course, h=
idden implementation costs. A lot more happens under the hood<br>during the=
 process, such as spawning Casper, communication with service and other<br>=
related operations. There has always seen a dilemma around whether we actua=
lly<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=
&#39;re talking about<br>tools that are not setuid/setgid and are potential=
ly as simple as=C2=A0</span>cut(1) or rev(1),<span>=C2=A0it introduces<br>s=
ignificant overhead that may outweigh the security benefits.</span></p>We h=
ad 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 stil=
l see opportunities to improve fileargs. For example, if the file descripto=
r limit is lower</div><div>than the fileargs cache size, then instead of sp=
awning Casper, we could simply cache the file</div><div>descriptors. I thin=
k that would address many of the performance concerns while preserving</div=
><div>most of the benefits.<br><br></div>If there are many opposing views, =
I would still suggest committing this change with the</div><div>feature dis=
abled by default and revisiting it once fileargs improvements are available=
.</div></div></div><br></div>Thanks,<br></div>Mariusz</div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, 4 Jun 2026 at 04:06, Adrian Chadd &lt;<a href=3D"mailto:adrian@fr=
eebsd.org">[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(20=
4,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>

--000000000000a8acd606536dd38b--