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