Re: chflags -RL and symlinks pointing outside the traversal: preserve behavior or add a Capsicum guardrail?

On Fri, Aug 21, 2026 at 4:33 PM Mark Johnston <markj@freebsd.org> wrote:
>
> On Sat, Aug 22, 2026 at 12:05:48AM +0200, Oliver Pinter wrote:
> > On Wed, Aug 19, 2026 at 6:11 PM Mark Johnston <markj@freebsd.org> wrote:
> >
> > > On Wed, Aug 19, 2026 at 09:40:35AM -0600, Alan Somers wrote:
> > > > I vote for #2.  Capsicumize the utility, and treat out-of-hierarchy
> > > > symlinks as an error.  I think that real users will almost never want to
> > > > follow out of hierarchy symlinks.  Also, even if this is a POLA
> > > violation,
> > > > it's extremely rare.  With grep, I couldn't find any example of chflags
> > > -RL
> > > > in the base system.  Github code search turned up a few.  Some were MacOS
> > > > Homebrew recipes that invoke chflags right after installing the package.
> > > > Those uses surely would prefer not to follow out-of--hierarchy symlinks.
> > > > The most interesting use I found was from quBSD, a jail/bhyve manager.  I
> > > > don't know if that project really intends to follow out-of-hierarchy
> > > > symlinks or not, but I've notified him.
> > >
> > > If we go this route, I think there does need to be a chicken switch for
> > > any users that are legitimately impacted and want an easy workaround.
> > > I'm not sure what that would look like: an environment variable, sysctl,
> > > new command-line option?  Should any such chicken switch be global,
> > > i.e., should it apply to all capsicumized utilities which use fts?  I
> > > presume you are planning to extend this to work with other fts-using
> > > utilities which might benefit more from running in a sandbox, like grep.
> > >
> >
> > What about introducing a sysctl AND a shared page metadata. As far as I
> > remember, FreeBSD already has a shared page for gettimeofday(?),
> > what about putting the capsicum sysctl state also to the shared page?
>
> This would save at most one syscall per program invocation, which
> doesn't seem expensive enough to justify the complexity.  Or am I
> misunderstanding something in your proposal.

A sysctl is also a global setting.  I don't think we want to set this
globally.  Better to set it only for those very rare scripts that need
it.  I like the CLI option approach better.