systemd-nspawn Advent Calendar 2017 13日目の記事です。
systemd-nspawnで最初にはまる罠（？）として--private-usersオプションがあります。
これどういうことかというとファイルのuid,gidをホスト側とぶつからないように、再マッピングしてくれる機能です。
例として、以下のような状態を想定します。
uid=1000(yamasita) gid=1000(yamasita) というユーザがホスト側に
uid=1000(cuser) gid=1000(cuser) というユーザがコンテナ側にあったとします
# /home/yamasitaとコンテナ側の/mntをつなげて起動
systemd-nspawn -D container/ --bind /home/yamasita:/mnt
# cuserになる
su - cuser
# 自由にディレクト触れてしまう
touch /mnt/hogehoge
コンテナ側のユーザもuid=1000番なので、cuserはホスト側の世界だとyamasitaユーザとしての権限を持ってしまいディレクトリに書き込めるというわけです
この挙動を意図していない場合は--private-users=pickという引数を使います
# /home/yamasitaとコンテナ側の/mntをつなげて起動
systemd-nspawn --private-users=pick -D container/ --bind /home/yamasita:/mnt
# cuserになる
su - cuser
# エラーになる
touch /mnt/hogehoge
# touch: cannot touch '/mnt/hogehoge': Permission denied
今度はエラーになりました。
これは、コンテナ内のユーザがホストに存在するユーザと重ならないように調整され、ホスト側から見ると違うユーザとして動いているからです。
（コンテナ側から見ると同じ1000番になっています。）
このオプションは暗黙的に--private-users-chownというオプションもONにして、ファイルの所有者も全部変更されますので、起動に若干時間がかかります。
ちなみに以下のようにすると、変わってしまった所有者情報を戻すことができます
systemd-nspawn --private-users=0 --private-users-chown -D container/
という感じでした。
これはこれでセキュアな環境を作るには良いんですが、気軽にやってしまうと思わぬbindを使ったホスト側とのファイル共有でトラブルを招くので注意してください