Appropriate path for mount/fsck sub-programs?

[John-Mark Gurney]

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).
> 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20200916/f80235f8/attachment.sig>