Bug 251409
| Summary: | getprogname(3) does not work for rescue binaries | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Alan Somers <asomers> |
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Overcome By Events | ||
| Severity: | Affects Many People | CC: | cem, emaste |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
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. 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. Can no longer reproduce in a recent 14.0-CURRENT or 13.1-RELEASE. |
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.