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

Adrian Chadd <[email protected]> Fri, 5 Jun 2026 07:46:28 -0700
Newsgroups gmane.os.freebsd.architechture
Message-ID <CAJ-Vmo=hbkhO28KyA=hCYN9pxt6K0g-tYkzGj8uWN00hxgHx7w@mail.gmail.com>
On Fri, 5 Jun 2026 at 04:14, Jamie Landeg-Jones <[email protected]> wrote:
>
> Adrian Chadd <[email protected]> wrote:
>
> > 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.
>
> Definitely. "cut" is often used for short-lived operations, often in
> loops etc.
>
> It would be a huge problem having another fork/exec in there.
>
> Can capsium be made optional at run time? Like being enabled with "-C" etc.?

I'd rather not add command line options / environment settings that can disable
sandboxing. These should be cheap operations.

This may be the wrong granularity to be doing these kind of sandboxing tasks.
There's been some side chats about the implications of trying to sandbox
these tools (eg opening all the files first and then calling
cap_enter() will change
the behaviour of the tools, since opening each file sequentially doesn't hold
a fd open which can reference a file as its been deleted / renamed..)



-adrian