---
id: admin
title: ユーザー管理 / 安全性
category: admin
order: 190
keywords: [ユーザー管理, 権限, admin, 安全性, bash, sandbox, 監査]
---

# ユーザー管理 / 安全性 (admin)

このページは admin が行う運用作業をまとめます。ユーザーの承認・権限付与、公開範囲モデル、そしてエージェントの安全制御 (Bash 実行・監査ログ) です。

## ユーザー管理

TopBar → **ユーザー** タブで開きます。左にユーザー一覧、右に選択ユーザーの詳細という 2 ペイン構成です。

### 一覧とフィルタ

- 上部に「すべて / Admin / User」のフィルタチップ。承認待ちのユーザーが居る場合のみ **承認待ち** チップも出る
- 名前 / メールで検索できる
- ユーザーは OAuth ログイン時に自動作成される。手動追加 UI はない (「OAuth ログインを行うとここに表示されます」)

### ロール

ユーザーは 2 つのロールのいずれかを持ちます。詳細パネルの「ロールと権限」で切り替えます。

| ロール | できること |
|--------|-----------|
| Admin | 全ての設定変更・ユーザー管理・システム操作 |
| User | タスク作成・実行など通常の利用。管理操作は不可 |

### ステータスと承認

| ステータス | 意味 |
|-----------|------|
| 承認待ち (pending) | 初回ログイン直後。まだ利用できない |
| アクティブ (active) | 利用可能 |
| 無効 (disabled) | ログイン不可に制限された状態 |

詳細パネルのヘッダにあるボタンで状態を変えます。

- **pending のユーザー** → 「承認」ボタンで active に
- **active のユーザー** → 「無効化」ボタンで disabled に
- **disabled のユーザー** → 「有効化」ボタンで active に戻す
- 「削除」ボタンでユーザーを完全に削除 (確認ダイアログあり)

> 最初の管理者をブートストラップするときは、DB を直接操作する手もあります: `UPDATE users SET role='admin', status='active' WHERE email='you@example.com'`。以降は別 admin がこの画面で昇格できます。

### 所属組織

Gitea でログインしたユーザーは、所属する Gitea organization が詳細パネルの「所属 Gitea 組織」に表示されます。これが下記の公開範囲「org」の判定に使われます。

## 公開範囲・権限モデル

タスク・スケジュール・ジョブは `owner_id` / `visibility` を持ち、3 段階の公開範囲を取ります。

| 公開範囲 | 見える人 |
|----------|---------|
| private | owner + admin |
| org | 同じ Gitea organization のメンバー |
| public | 全ログインユーザー |

ポイント:

- **admin は全件閲覧可能**。ただし編集・削除は owner または admin のみ
- 権限チェックは `buildVisibilityWhere(user, alias)` を一覧・取得クエリに差し込む形で一元化されている
- 親 → 子へ公開範囲がコピーされる (タスク → その spawn job、スケジュール → spawn job、親 job → 子 subtask)

## 安全性: Bash 実行モード

エージェントの `Bash` ツールの隔離は、`config.yaml` の **2 つの独立したキー**で制御します。どちらも設定 UI には出ない **config ファイル専用キー**です（危険なセキュリティ姿勢キーは UI トグルにせず、config 直編集 + 再起動を要求する方針）。

- `safety.bash_sandbox` — **隔離機構**を選ぶ。`auto`（既定）/ `always` / `off`
- `safety.bash_unrestricted` — **コマンド許可リストを適用するか**だけを制御（既定 `false`）。bwrap が走るかどうかは制御しない（それは `bash_sandbox` の役割）

### 隔離機構 (`safety.bash_sandbox`, 既定 `auto`)

| 値 | 挙動 |
|----|------|
| `auto`（既定） | bwrap があれば bwrap サンドボックス、無ければ hardened フォールバック |
| `always` | bwrap を強制。bwrap 不在なら**起動失敗**（本番推奨） |
| `off` | bwrap を使わず exec（**env スクラブは維持**）。デバッグ用・非推奨 |

### bwrap サンドボックス（`auto`+bwrap / `always`）

- 書き込み可能は **そのタスクのワークスペースのみ**。`/usr` `/bin` 等は read-only bind。他タスクの workspace やホスト `/home` は mount されず横断アクセス不可
- ユーザー名前空間・PID・IPC・UTS・cgroup・**ネットワーク**を unshare
- **各 Bash コールは独立したサンドボックス**（揮発 `/tmp`・毎回新しい名前空間）。コマンド間で残るのは workspace だけ
- **環境変数**: `--clearenv` 後に `PATH`/`HOME`/`LANG` 等の最小 allowlist のみ注入。`MCP_ENCRYPTION_KEY` 等のシークレットはサンドボックス内から見えない
- **ネットワーク**: `--unshare-net` で遮断。外向き通信は SSRF ガード付きの WebFetch / DownloadFile / MCP 経由に一本化
- **前提**: user namespace が有効 + `bwrap`。`always` は起動時に動作確認し、利用不可ならエラーで起動中止 (`Bash sandboxing requires bwrap but it is not available`)

### hardened フォールバック（bwrap 不在時の `auto` / `off`）

- 許可リスト照合（`bash_unrestricted: false` のとき）+ パススコープチェック（相対 `..` での workspace 外参照も拒否）+ env スクラブ付き exec
- プロセス単位の FS / ネットワーク名前空間分離は無く、bwrap より弱い多層防御。**本番は `always` 運用を推奨**

### コマンド許可リスト (`safety.bash_unrestricted`, 既定 `false`)

- `false`: 許可リストで照合し、ワークスペース外を触るコマンドはパススコープで拒否。ブロックはツール結果に返り `logs/` に記録
- `true`: 許可リストを撤廃し任意コマンド名を実行可能。**ただし FS / env / ネットワークの隔離は `bash_sandbox` が決めるので引き続き有効**

### パッケージのインストール

- `pip install` / `npm install` は**全モードで拒否**される（各コールが独立サンドボックスのためインストールは永続しない）。ブロック時はプリインストール済みパッケージ一覧を返す
- 必要な Python パッケージは `runtime/python-requirements.txt` にプリベイクされ、システム python（read-only bind）から import 可能。追加が必要なら同ファイルに足して再プロビジョニングする（手順: `docs/operations/bash-sandbox-provisioning.md`）

> 本番は `bash_sandbox: always` + パッケージのプリベイクを推奨。bwrap が使えないホストでは `auto`（hardened フォールバック）になるが、テナント間分離は弱くなる点に注意。

## 監査ログ

- ジョブ実行に関する操作は `audit_log` テーブル (`action` / `actor` / `detail` / `created_at`) に記録される
- Bash の実行履歴はワークスペースの `logs/` 配下に残る (ブロックされた試行も含む)
- SSH ツールの呼び出しは別途、SSH 専用の監査ログに記録される (設定 → SSH → Audit Log)。詳細は [SSH リモート操作](./14-ssh.md) を参照

## TIP

> 公開範囲・worker・各種上限の設定そのものは [システム設定](./17-settings.md) 側で行う。このページは「誰が・何を・どこまで」の運用判断に集中する。

> 承認待ちユーザーが溜まると一覧上部に件数が出る。放置せず承認 / 無効化で捌く。
