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