Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Actor rootfs `/` is mode 0700, so non-root users cannot traverse the root filesystem

オープン 初心者向け
  • 何か問題がありますか？
#2,035 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
76/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go, linux
領域
operating-systems

調査の方向性

internal/imagecache/bundle_linux.go:61-66 から始め、81 行目の overlay mount の前に rootfs、upper、work がどのように作成されるかを確認してください。internal/imagecache/implicitdirs.go の applyDirFixups を読み、統合された root が処理されるかどうかを判断してください。標準イメージの root が非 root ユーザーから引き続き辿れる状態になり、報告された 0700 root の挙動に対するリグレッションチェックがあれば完了です。

索引モデルが issue の本文から書いたものです。

説明

area/gvisor area/node kind/bug

Summary

Inside a gVisor actor, the root directory / is root:root 0700. A workload that drops to a non-root user cannot resolve any path at all, not even /bin/sh, because the first path component is not traversable. Docker and containerd keep the image root's mode (normally 0755). As shipped, any non-root workload fails on Substrate.

Impact

  • Who hits it: every integrator whose workload runs as, or switches to, a non-root user. Agent runtimes and most hardened images do this.
  • What breaks: su, runuser and any exec as a non-root uid fail with Permission denied. The workload cannot start.
  • Cost: each integrator has to add a root-privileged fixup at actor start.
  • Severity: High.
  • Proposed priority: P1. It blocks non-root workloads out of the box. A workaround exists but needs root at startup, which depends on the uid-0 start (see Workload has no user field or no-new-privileges setting…).

Environment

  • Substrate d277088b (v1alpha).
  • GKE 1.36.x.
  • gVisor sandbox class, unprivileged WorkerPool workers.

Steps to reproduce / evidence

  1. Create the actor (verified live). Use an ActorTemplate whose image is a Debian-based image with a non-root user (for example useradd -u 1000 agent). Create an actor from it.
  2. Check the root mode inside the actor, as root (verified live): 
    $ stat -c '%a:%U:%G %n' /
700:root:root /
  3. Switch to the non-root user (verified live): 
    $ su agent -s /bin/sh -c id
su: failed to execute /bin/sh: Permission denied
    /bin/sh is itself 0755. The failure is at the traversal of /.
  4. Show that a 0755 root is sufficient (verified live). After chmod 755 / (as root), su and runuser to the non-root uid both succeed. The same test also chowned the user's home directory; the exec itself (su … -c id) depends only on / being traversable.
  5. Cause (code-read at d277088b):
    • internal/imagecache/bundle_linux.go:61-66 creates <bundle>/rootfs, upper and work with os.MkdirAll(d, 0o700).
    • The overlay is then mounted at rootfs with that upperdir (bundle_linux.go:81).
    • The merged overlay root takes its attributes from the upperdir root.
    • applyDirFixups in internal/imagecache/implicitdirs.go repairs implicit parent directories. It does not appear to cover / itself.

Expected vs actual

  • Expected: the actor's / has the image root's mode (0755 for standard base images), as under Docker, containerd and Kubernetes.
  • Actual: / is 0700 and owned by root. No non-root uid can traverse it.

Workaround

At actor start, while still uid 0, an integrator can:

  1. chmod 755 / if / is more restrictive than that.
  2. Check that the workload user can traverse the rootfs (for example that /bin/sh resolves).
  3. Fail closed if it cannot.

This only works because the workload starts as root.

Additional detail

  • Suggested fix: create the bundle rootfs/upperdir root with 0755, or copy the image root's mode onto it after the overlay is mounted.
  • Related issues (same class, image metadata lost in the actor rootfs):
    • Image-layer file ownership appears as uid 0 inside the actor (image-layer-file-ownership-lost.md).
    • Actor rootfs drops setuid, setgid and sticky bits from image layers (/tmp is 0777) (actor-rootfs-drops-special-mode-bits.md).
主要言語
Go
スター
4.4k
フォーク
515
平均マージ
2日 10時間
マージ済み PR（30日）
311

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

agent-substrate/substrate のほかの issue

agent-substrate/substrate の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。