[FEAT] exePath Implementation for OpenBSD

[samuelvenable]

Description

It is technically possible to do, even if there are a few failure cases. For instance, here's a C++ project I wrote which does it: https://github.com/samuelvenable/OpenBSD-Get-Executable-Path The code would need to be rewritten to be in C, but the same basic code logic would be used. Some of the code logic might be omitted or considered redundant depending on your needs. OpenBSD has no official API for this, so I admit, writing our own solution is pretty hacky. It tests against the ino_t and dev_t of the file to make sure it matches up with a valid hard link to the exact intended file. It returns an empty string when it fails, as you documented. I got help from the OpenBSD mailing lists to write this solution, so it's as good as it things get.

The only dependencies are libc and libkvm which are provided by OpenBSD's base system.

Motivation

This is mainly for consistency with other platforms. OpenBSD is the only platform missing this feature.

https://github.com/fastfetch-cli/fastfetch/blob/a1e20270ad76a38d9098fe404acfac472820e67c/src/common/impl/FFPlatform_unix.c#L49C9-L49C31

Additional context

No response

[CarterLi]

It tests against the ino_t and dev_t of the file to make sure it matches up with a valid hard link to the exact intended file

So it's still based on argv[0]. But with the extra verification I think it's acceptable.

I got help from the OpenBSD mailing lists to write this solution

I was told that missing an API to query the exe path of current process is a security feature. In additon, OpenBSD is the only BSD system that requires root permission to enumerate PCI devices. What a security-oriented system...

[samuelvenable]

You already know this, but just as a reminder since my code I gave doesn't actually address this particular edge case:

Even though the path returned is guaranteed to return a valid hard link to the correct file if the function succeeds, if argv[0] is modified, there is still an obscure chance the hard link returned corresponds to a path which is not the same one the process spawned from.

To solve this, have the function fail and return an empty string whenever the st_nlink member of the stat structure returns something besides one, to verify whether there is only one hard link in existence.

[CarterLi]

    if ((kif = kvm_getfiles(kd, KERN_FILE_BYPID, getpid(), sizeof(struct kinfo_file), &cntp))) {
      for (int i = 0; i < cntp && kif[i].fd_fd < 0; i++) {
        if (kif[i].fd_fd == KERN_FILE_TEXT) {
          struct stat st;
          fallback:
          char buffer[PATH_MAX];
          if (!stat(exe.c_str(), &st) && (st.st_mode & S_IXUSR) &&
            (st.st_mode & S_IFREG) && realpath(exe.c_str(), buffer) &&
            st.st_dev == (dev_t)kif[i].va_fsid && st.st_ino == (ino_t)kif[i].va_fileid) {
            res = buffer;
          }

Is there an edge case: what if arg0 is a .so file which is currently loaded by the process?

[samuelvenable]

As far as I'm aware, KERN_FILE_TEXT is a single file descriptor present once in every process, and is a negative number representing the current executable and not an .so library loaded by it.

Edit:

I'll try modifying argv[0] to a .so loaded by the executable and see if that breaks this.

[samuelvenable]

int main(int argc, char **argv) {
  argv[0] = (char *)"/usr/lib/libkvm.so.18.0";
  std::string exe = get_executable_path();
  bool failed = exe.empty();
  if (!failed) {
    printf("get_executable_path() result: %s\n", exe.c_str());
  } else {
    printf("get_executable_path() error: %s\n", strerror(errno));
  }
  return failed;
}

Even though I modified argv[0] it still printed the executable, my guess is because of my p_comm[KI_MAXCOMLEN] fallback.

I think if it wasn't for that, the function would have failed because it didn't recognize argv[0] as an executable hard link.

Edit:

Sorry for the typos. The above code snippet was not a direct copy/paste of what I tested. Copied it manually from a different machine.