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

Adrian Chadd <[email protected]> Thu, 4 Jun 2026 07:30:17 -0700
Newsgroups gmane.os.freebsd.architechture
Message-ID <CAJ-Vmoks4dE5j5=b9i=QCqEA8f1p=cKUd2WggY64fnjhebrbCg@mail.gmail.com>
On Thu, 4 Jun 2026 at 06: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.

This is precisely why I asked :-) If it requires spawning a service
every time cut / rev is run,
I'm pretty sure the FreeBSD shell developers are going to get very
angry at me and quite
rightly so!

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

This is good feedback. I just looked at cat too, and yes it looks like
you disabled it in 2021
for performance reasons. I think we should go chase this up some more;
I too would like
to see more base utilities sandboxed but if it's going to involve
fork/exec'ing another service
for /each invocation of a binary/ rather than simply limiting the
capabilities of the current
process, it .. just feels too heavy weight.

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

I think this is the right thing to do. I'll go poke Nick to update his
diff to do that for now.



-adrian