Bug 251409 - getprogname(3) does not work for rescue binaries
Summary: getprogname(3) does not work for rescue binaries
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-26 18:40 UTC by Alan Somers
Modified: 2020-12-02 16:01 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Somers freebsd_committer 2020-11-26 18:40:47 UTC
Some utilities (e.g. reboot, ping, fsck_ffs) install multiple hard links and use getprogname(3) to tell which was invoked, triggering different behavior based on the name of the invoked link.  However, when built as part of rescue(8), getprogname doesn't work.  It always returns the same name, regardless of how the binary was invoked.  For example:

> /rescue/fsck_ffs --help
fsck_ffs: illegal option -- -
usage: /rescue/iscsid [-BCdEFfnpRrSyZ] [-b block] [-c level] [-m mode] filesystem ...

Notice that the usage string contains "/rescue/iscsid", which is obviously not correct.
Comment 1 Conrad Meyer freebsd_committer 2020-11-26 21:47:53 UTC
I think this is due to the __progname logic in usr.sbin/crunch/crunchgen/crunched_main.c, which takes the name from AT_EXECPATH, which is derived from vn_fullpath() in do_execve in sys/kern/kern_exec.c.  vn_fullpath cannot tell hardlink names for the same inode apart.  The logic in crunched_main.c is wrong for hardlinked binaries, I think.
Comment 2 Conrad Meyer freebsd_committer 2020-11-26 21:51:34 UTC
Actually, still not sure why that's messing up __progname.  But I suspect the origin of the bogus link-name is the kernel via auxargs, and the weird __progname that isn't coming from argv[0] is somewhere in the crunchgen code.