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

On Sat, Aug 22, 2026 at 12:05:48AM +0200, Oliver Pinter wrote:
> On Wed, Aug 19, 2026 at 6:11 PM Mark Johnston <[email protected]> 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.