Repository navigation
Let any uid configure a project on ESP-IDF 5.5.6 - #58
Merged
Merged
Conversation
ESP-IDF 5.5.6 ships tools/idf_extra_components.yml, and its presence makes the component manager write $IDF_TOOLS_PATH/root_managed_components/idf5.5/dependencies.lock on every configure. /opt/esp belongs to root, so under the documented `-u $(id -u):$(id -g)` every project failed at configure with a PermissionError, while every check, run as root, stayed green. Both ESP images now ship that directory empty at mode 1777. The esp-idf verification layer configures hello_world as an arbitrary uid and returns the directory empty; esp-matter creates it too, for bases that predate the layer, and asserts install.sh left it empty.
Review findings on the previous commit: - tell a missing setpriv from one that cannot drop privileges; - go through the image's entrypoint, as `docker run` does; - switch targets after the first configure, the path that rewrites the lock; - require the lock to exist and belong to the probe's uid where the SDK ships idf_extra_components.yml, so the probe cannot pass untouched; - refuse an unset IDF_TOOLS_PATH in both images instead of creating /root_managed_components; - quote $(pwd) in the new README example. Also point the probe's TMPDIR at its scratch directory and assert nothing of its uid is left in /tmp or /var/tmp: export.sh otherwise left /tmp/esp_idf_activate owned by that uid, the directory it uses under every uid without a passwd entry.
There was a problem hiding this comment.
🟢 Approved
No unresolved blocking issues remain.
No open issues 🎉
What changed in this PR
Fixes ESP-IDF 5.5.6 configuration for non-root container users.
Changes:
- Adds writable component-manager storage and validation.
- Applies compatibility setup to ESP-Matter images.
- Documents non-root usage and
HOMErequirements.
| File | Description |
|---|---|
images/esp-matter/README.md |
Links to ESP-IDF non-root build guidance. |
images/esp-matter/Dockerfile |
Adds compatibility setup for inherited base images. |
images/esp-idf/README.md |
Documents non-root builds and limitations. |
images/esp-idf/Dockerfile |
Creates and validates writable component-manager storage. |
Review effort: Lite
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Образы ESP-IDF v5.5.6 из #57 ломают сборку под задокументированным
-u $(id -u):$(id -g): CMake configure любого проекта падает сPermissionError: '/opt/esp/root_managed_components'. Нашёл потребитель — батч jethome-iot/jetcontrol-cpp#2005: так у него ломалась каждая ESP32-сборка. Сборка от root, в том числе собственный слой проверки образа, продолжала проходить.Почему так
В ESP-IDF 5.5.6 появился
tools/idf_extra_components.yml(все строки закомментированы). Как только этот файл есть, менеджер компонентов (prepare_dep_dirs) при каждом configure пишет$IDF_TOOLS_PATH/root_managed_components/idf5.5/dependencies.lockи сначала создаёт этот каталог./opt/espпринадлежит root. В 5.5.5 файла не было.Обойти это переменной окружения нельзя. Каталог выводится только из
IDF_TOOLS_PATH(idf_component_tools.config.config_dir(), запасной вариант —~/.espressif), а поIDF_TOOLS_PATHобраз находит тулчейны. Готовый lock, созданный при сборке от root, тоже не подходит: в нём записанtarget, и при каждой смене цели файл переписывается на месте (open(path, 'w')). Проверено: под чужим uid отказ случается на первом жеset-target.Что изменилось
images/esp-idf/Dockerfile:install -d -m 1777 "${IDF_TOOLS_PATH:?}/root_managed_components". Создаётся пустым и только верхний уровень: подкаталогidf<major.minor>заводит первый uid, выполнивший configure, и дальше он принадлежит этому uid. Один uid на контейнер — то, что даётdocker run -u, — проходит на любой цели. Второй uid в том же контейнере падает при смене цели. Комментарий и README об этом говорят прямо;hello_worldпод uid 54321, у которого нет записи в passwd, через entrypoint образа: сначала цель по умолчанию, затемset-target esp32c3. Если в SDK естьidf_extra_components.yml, слой требует, чтобы lock появился и принадлежал этому uid; в 5.4.1 этого файла нет.HOMEиTMPDIRнаправлены во временный каталог проверки. Затем слой удаляет изroot_managed_componentsвсё, что записал этот uid, и проверяет режим 1777 и что в/tmpи/var/tmpот этого uid ничего не осталось. Еслиsetprivнет или он не может сбросить привилегии, слой так и сообщает, как это уже делает esp-matter.images/esp-matter/Dockerfile— тот жеinstall -d(идемпотентный) для баз, собранных до этого слоя: на них, в том числе на уже опубликованномidf-v5.5.6, локальная сборка esp-matter иначе снова сломалась бы под-u. Слой проверки требует, чтобы каталог оставался пустым и с режимом 1777 послеinstall.sh, который выполняется от root.images/esp-idf/README.md— раздел Building as Your Own User: пример с-uи-e HOME=/tmp, что образ подготовил для этого случая и чего не покрывает. ЗаписываемыйHOMEпо-прежнему за вызывающим: без него configure падает на кэше менеджера компонентов (~/.cache/Espressif/ComponentManager). Так было и на 5.5.5.images/esp-matter/README.md— абзац о-uссылается на этот раздел.Файл SDK
idf_extra_components.ymlне меняется — так просил потребитель.Как проверено
Локально,
./scripts/build.sh esp-idf(linux/arm64,IDF_BASE_TAG=v5.5.6):configure as uid 54321, esp32 then esp32c3: okPermissionError,configure as uid 54321 failedroot_managed_componentsв образе1777 root, пустой; в/tmpот uid 54321 ничего нет (до исправления оставался/tmp/esp_idf_activateэтого uid)-u $(id -u):$(id -g) -e HOME=/tmphello_worldсобирается для esp32, затемset-target esp32c6и снова собирается;build/принадлежит вызывающему-uPermissionError; на опубликованномidf-v5.5.6-r39022168715.1его воспроизвёл потребительcheck-versions.sh,check-pins.sh,lint.shesp-matter и вариант
idf-v5.4.1локально не собирались: для esp-matter нужно около 50 ГБ диска, а свободно меньше. Их проверяют сборки CI на этом PR, где esp-matter собирается поверх esp-idf этого же запуска.Локальное ревью — раунд уровня high. У Claude полное покрытие, у Codex частичное: ему не хватило сети, чтобы прочитать Dockerfile базовых образов. Девять находок
Minor. Шесть исправлены в30d0476: различение отсутствующегоsetpriv, путь через entrypoint, смена цели, требование lock-файла,${IDF_TOOLS_PATH:?}, кавычки вокруг$(pwd). Три отклонены:idf_extra_components.yml— потребитель просил файл SDK не трогать, а с первым же раскомментированным пакетом upstream это решение сломалось бы;HOME— требование существовало и до 5.5.6, это отдельное решение об окружении образа.Исправление с
TMPDIRи проверку остатков в/tmpпосле этого ещё раз прочитал Codex: полное покрытие, находок нет.После слияния воркфлоу ESP-IDF опубликует новые
idf-v5.5.6-r<run>.<attempt>иidf-v5.5.6-matter-v1.6-r<run>.<attempt>— их передадут в jethome-iot/jetcontrol-cpp#2005.