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

On Fri, 21 Aug 2026 17:00:35 -0600
Alan Somers <[email protected]> wrote:

> On Fri, Aug 21, 2026 at 4:33 PM Mark Johnston <[email protected]> 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 <[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.
> 
> 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.

Sysctl would be good for specifying site (organizaiton) default
not to be missed.
In this case, command line option would need both for enabling
and disabling.

So it comes back to "is it worth doing?" question.
Different points of views would give different opinions.

Regards.

-- 
Tomoaki AOKI    <[email protected]>