【要約】rootfsをGitで管理して痛い目に遭った話と、ペンテストに対応できる開発環境の作り方 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
- ・rootfsをGitで直接管理すると、setuidビット等の詳細な権限が消失する。
- ・GitのTreeオブジェクトは、保持できるモードが100644, 100755, 120000に限定される。
- ・結果、実機展開時にsudo等の管理者権限昇格が不能になる。
- ・Yoctoの採用には、学習コストやビルド環境の制約という課題があった。
// Approach
1.rootfs自体はGit管理せず、ベースのtar.gzを展開する方針へ転換。
2.各コンポーネント（kernel, U-Boot等）をGit submoduleとして管理。
3.qemu-arm-staticとchrootを用い、x86ホスト上でARM環境を構築。
4.depmod -b を使い、ホスト側からrootfs内のモジュール依存関係を解決。
5.運用アップデート（ipk）とキッティング（SDイメージ）の2系統のビルドパスを構築。
// Result
- ・パーミッション崩壊を防ぎ、安定したrootfs構築を実現。
- ・アプリケーションからカーネル、ブートローダーまで、全レイヤを跨ぐ脆弱性修正が可能に。
- ・第三者ペネトレーションテストに対し、迅速な対策と検証ができる体制を確立。
Senior Engineer Insight
> 「理想のYocto」を捨て、「運用の実効性」を取った判断は極めて実践的だ。Gitの仕様（Treeオブジェクトの制限）を理解した上での方針転換は、組み込み開発における定石と言える。運用とキッティングのビルドパス分離は、可用性とセキュリティの両立において不可欠な設計だ。ただし、コンポーネントが増大した際の依存関係管理の複雑化には注意が必要である。