Appropriate path for mount/fsck sub-programs?

[Rodney W. Grimes]

> --------
> Brooks Davis writes:
> 
> > 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.
> 
> Why are we even bothering with _PATH_SYSPATH in the first place ?
> 
>     A) Being able to find the subprograms  ?
> 
> or
> 
>     B) Not running random binaries ?
> 
> I'd call B a bogus strawman:  If we do not trust root's PATH, we
> should not trust /bin/sh to find the right fsck(8) in the first
> place.

I can support this statement.

> 
> So if the concern only to find the subprograms, we should use ${PATH},
> but since fsck is a Very Important Program for bringing systems up,
> we should have a user-friendly fall-back.

I am not so sure on this one.

> 
> So my proposal 5):
> 
> 	Use ${PATH}, on failure search through a list of
> 	Well-Known-Directories, and ask the user for confirmation:
> 
> 		fsck -t foofs /dev/da0
> 		fsck error: fsck_foofs not found in $PATH.

I would just stop right here, this gives clear indication
of the source of the issue, PATH does not contain a proper
binary and at this point the administrator can fix PATH.

> 		Use /rescue/fsck_foofs Y/N ?
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org