1

I have been using boost 1.65, did not change the code, updated boost to version 1.71 and now suddenly boost::process::child("command-in-path") does not inherit the environment of the executing process. How can I recover the behavior, is it possible without parsing the command every time to find the executable in path?

Yuki
  • 3,857
  • 5
  • 25
  • 43
  • 1
    I wonder why people downvoted your post. Perhaps it is because of a lack of code. You could easily have added ~3 surrounding lines of code to make the sample self-contained, I guess. – sehe Feb 16 '21 at 15:45

1 Answers1

3

I haven't checked whether the behaviour actually changed, but I know there's a way to explicitly allow Boost to search the path:

Keep in mind that searching the path can easily be a security issue because it can be compromised, or attackers can leverage knowledge of the path setting to intercept executables. This is why you'd expect search_path to be OFF by default (except for the system interface, which is traditionally insecure)

Live On Wandbox

#include <boost/process.hpp>

int main() {
    namespace bp = boost::process;

    bp::child c(
        bp::search_path("date"),
        std::vector<std::string> { "+%s" });
    c.wait();
}
sehe
  • 374,641
  • 47
  • 450
  • 633
  • Thank you for the flaws explanation, however, I do not think it is a danger in my application. So if my command consists of more than just executable, i.e. executable and several arguments. I have to break it into tokens, no other way. Cause in 1.65 I could just pass one string. – Yuki Feb 16 '21 at 17:20