Appropriate path for mount/fsck sub-programs?

[Rodney W. Grimes]

-- Start of PGP signed section.
> Brooks Davis wrote this message on Wed, Sep 16, 2020 at 20:42 +0000:
> > The mount and fsck commands have the ability to exec a mount_<fs> or
> > fsck_<fs> program to do the actual work.  Currently they do this with:
> > 
> > execvP(execname, _PATH_SYSPATH, argv);
> > 
> > Where _PATH_SYSPATH is "/sbin:/usr/sbin" unless RESCUE is defined in
> > which case it's "/rescue:/sbin:/usr/sbin".  This isn't very friendly to
> > filesystems in ports and results in things like sysutils/e2fsprogs
> > adding a link to /sbin.  I think the path should be expanded to include
> > /usr/local/sbin at a minimum.  If it wasn't for the /rescue hack I'd be
> > tempted to suggest just switching to `execvp` and using PATH.
> > I see a few options (semi-sorted by level of change):
> > 
> > 0) Do nothing
> > 1a) Add /usr/local/sbin to _PATH_SYSPATH (it's only used in mount and
> >    fsck).

I would like to note that /usr/local is a choice made by a site
and not an absolute global constant.  PREFIX can usually used
to over ride this.

The assumption of /usr/local was once completly removed from
FreeBSD and the ports system.  It has slowly crept back in
and many places now contain hard coded, not easy to override
constants.

This is yet another proposal to hard code this non-constant.

> > 1b) The same, but a new variable.
> > 2) Switch to _PATH_DEFPATH (that also add .../bin directories).
> > 3) Use PATH, optionally prepending /rescue
> > 4) Use exevp and teach crunched_main.c to prepend /rescue to PATH.
> > 
> > I'd like opinions on what people think makes sense here.  I think (0)
> > aligns poorly with current project directions, but how far to go is a
> > question to answer before implementing something.
> 
> Since it's only used by fsck and mount, I'm firmly in the 1a camp..
> 
> This means that mount_* programs can be located in /usr/local/sbin as
> well, which seems to complete this change...
> 
> 2 would make fsck_* programs "visible" when ports don't do the correct
> thing, which 1b helps prevent.
> 
> 3 and 4 are dangerous to me, as it not everyone keeps . out of their
> path, and might be tricked into running a bad binary..
> 
> -- 
>   John-Mark Gurney				Voice: +1 415 225 5579
> 
>      "All that I will do, has been done, All that I have, has not."
-- End of PGP section, PGP failed!

-- 
Rod Grimes                                                 rgrimes at freebsd.org