exec: "bash": cannot run executable found relative to current directory

[limingjie]

Board

ESP32S3 Dev Module, ESP32 Dev Module

Device Description

The issue happens while compiling, a dev board is not required to reproduce the issue.

Version

2.0.12

IDE Name

Arduino IDE Version: 2.2.1

Operating System

macOS Ventura 13.5

Description

I saw this issue in a WeChat group. The compilation step fails if the PATH variable has a relative path. This is probably due to the security restriction of exec() that is used by Arduino, using a relative path gives the hacker a chance to replace the binary and potentially gain restricted access.

Reproduce Steps

The issue reproduces in macOS.

1. If you are not using zsh, change to zsh.

chsh -s /bin/zsh

2. Add a relative path into the $PATH env var. For example, append the following line at the end of ~/.zshrc.

export PATH="./bin:$PATH"

3. Close and restart Arduino IDE 2.2.1.
4. Select board ESP32S3 Dev Module or ESP32 Dev Module.
5. Try compiling any example sketch.

Solution

In platform.txt, replace bash with /usr/bin/env bash to ignore the search path, the issue is gone.

Error Log

FQBN: esp32:esp32:esp32s3
Using board 'esp32s3' from platform in folder: /Users/mingjie.li/Library/Arduino15/packages/esp32/hardware/esp32/2.0.12
Using core 'esp32' from platform in folder: /Users/mingjie.li/Library/Arduino15/packages/esp32/hardware/esp32/2.0.12

bash -c "[ ! -f \"/Users/mingjie.li/Documents/Arduino/BlinkRGB\"/partitions.csv ] || cp -f \"/Users/mingjie.li/Documents/Arduino/BlinkRGB\"/partitions.csv \"/private/var/folders/np/q95x8dw97611nmm409kr7znc0000gp/T/arduino/sketches/094B1C89E47FE775C5AE52E3FF7017B5\"/partitions.csv"

exec: "bash": cannot run executable found relative to current directory

Compilation error: exec: "bash": cannot run executable found relative to current directory

Sketch

Any sketch will do, to quickly reproduce it, I used the blink one.

/*
  BlinkRGB

  Demonstrates usage of onboard RGB LED on some ESP dev boards.

  Calling digitalWrite(RGB_BUILTIN, HIGH) will use hidden RGB driver.
    
  RGBLedWrite demonstrates controll of each channel:
  void neopixelWrite(uint8_t pin, uint8_t red_val, uint8_t green_val, uint8_t blue_val)

  WARNING: After using digitalWrite to drive RGB LED it will be impossible to drive the same pin
    with normal HIGH/LOW level
*/
//#define RGB_BRIGHTNESS 64 // Change white brightness (max 255)

// the setup function runs once when you press reset or power the board

void setup() {
  // No need to initialize the RGB LED
}

// the loop function runs over and over again forever
void loop() {
#ifdef RGB_BUILTIN
  digitalWrite(RGB_BUILTIN, HIGH);   // Turn the RGB LED white
  delay(1000);
  digitalWrite(RGB_BUILTIN, LOW);    // Turn the RGB LED off
  delay(1000);

  neopixelWrite(RGB_BUILTIN,RGB_BRIGHTNESS,0,0); // Red
  delay(1000);
  neopixelWrite(RGB_BUILTIN,0,RGB_BRIGHTNESS,0); // Green
  delay(1000);
  neopixelWrite(RGB_BUILTIN,0,0,RGB_BRIGHTNESS); // Blue
  delay(1000);
  neopixelWrite(RGB_BUILTIN,0,0,0); // Off / black
  delay(1000);
#endif
}

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[VojtechBartoska]

@me-no-dev can you please take a look?

[me-no-dev]

how should we reproduce this?

[limingjie]

@me-no-dev Thanks for the reminder! I added a `Reproduce Steps section.

Reproduce Steps

The issue reproduces in macOS.

1. Add a relative path into the $PATH env var. For example, append the following line at the end of ~/.bashrc.

export PATH="./bin:$PATH"

2. Close and restart Arduino IDE 2.2.1.
3. Select board ESP32S3 Dev Module or ESP32 Dev Module.
4. Try compiling any example sketch.

[tomhobson]

I'm also getting this error! on MacOS 13.5 (22G74) (M1)

[me-no-dev]

@limingjie I tried adding relative search path, but CI did not fail?
https://github.com/espressif/arduino-esp32/pull/8622/files#diff-69e60b602c9704198a3cf61eea0e6673e3ced88c6279d830c31c2a15a63c3154R8

[me-no-dev]

I also can not reproduce this on my M1 Mac with either old and new IDEs

[limingjie]

@me-no-dev The relative path must be added to the ~/.bashrc (and ~/.zshrc if you are using Z shell), so that the Arduino IDE can use it to search executables.

[me-no-dev]

@limingjie I made sure that the IDE sees that path as well (added a line to print out the PATH). That did not make it fail (same goes for CI). There must be something else at play here... I tried different boards/chips too.

[limingjie]

@me-no-dev That's interesting, is it possible related to the Arduino IDE version or arduino-esp32 version?

I recorded the steps and attached the recording here.
https://github.com/espressif/arduino-esp32/assets/6889308/74c0b5f2-450b-4d4b-9dd3-6c5c66e67e96

[me-no-dev]

I do the same exact thing (plus I added a line to print out the PATH while building). Mac OS 13.5.2 (M1 MAX) + ArduinoIDE 2.2.1, but can not get it to fail... I tried with both install from BoardManager and from Git... we must be missing something else... BTW default shell for me is bash and not zsh

[limingjie]

@me-no-dev Are you reproducing by adding both the relative path and replacing bash with /usr/bin/env bash at the same time? The latter one is a fix, so in this case it won't reproduce.

Based on the changes in https://github.com/espressif/arduino-esp32/pull/8622/files#diff-69e60b602c9704198a3cf61eea0e6673e3ced88c6279d830c31c2a15a63c3154R8

[me-no-dev]

Of course not :) I tested separately even in the PR. First I added the relative path, then I added the fix to see if anything will break in either case. On my computer I tested over the release 2.0.12, which does not have the fix added at all.

[limingjie]

@me-no-dev I tried several different scenarios today, and finally, found it is related to zsh and seems to have nothing to do with bash at all, I've updated the reproduce steps, can you try again? Thank you for your patience!

1. If you are not using zsh, change to zsh.

chsh -s /bin/zsh

2. Add a relative path into the $PATH env var. For example, append the following line at the end of ~/.zshrc.

export PATH="./bin:$PATH"

3. Close and restart Arduino IDE 2.2.1.
4. Select board ESP32S3 Dev Module or ESP32 Dev Module.
5. Try compiling any example sketch.

[limingjie]

My zsh version is 5.9, if the default zsh cannot reproduce the problem, please install it by brew install zsh.

$ zsh --version
zsh 5.9 (arm-apple-darwin22.1.0)

[me-no-dev]

Did all that. ZSH is default on my system, updated with brew to the same version as you... compiles fine

[limingjie]

😂 I have no idea if there is any other difference on my laptop.

[me-no-dev]

we can try to fix this for 3.0.0. We will release betas and RCs of it first to catch possible issues in other environments. Will release 2.0.13 now and you can add the fix manually again. Next release will have it in :)

[limingjie]

Thank you!

[per1234]

This is probably due to the security restriction of exec() that is used by Arduino

That is correct. It is documented here:

https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_directory

will not resolve a program using an implicit or explicit path entry relative to the current directory. That is, if you run exec.LookPath("go"), it will not successfully return ./go on Unix nor .\go.exe on Windows, no matter how the path is configured. Instead, if the usual path algorithms would result in that answer, these functions return an error err satisfying errors.Is(err, ErrDot).

https://cs.opensource.google/go/go/+/master:src/os/exec/exec.go;l=1303

var ErrDot = errors.New("cannot run executable found relative to current directory")

This behavior of the Go exec package was introduced in Go 1.19, which was used starting from Arduino CLI 0.30.0 (arduino/arduino-cli#2026) / Arduino IDE 2.0.4 (arduino/arduino-ide#1909), so those using older versions of the Arduino development tools won't be able to reproduce the error.

There is a report here of it happening with the cmd executable used in the Windows command patterns. I can reproduce it using a contrived setup but as of the time I write this, haven't found how it could occur under more realistic conditions (it is possible more information will emerge as the discussion in the linked forum thread proceeds).

[me-no-dev]

Is this still valid?