正体はまさかの旧アカウントでした。ターミナルを開くたびに出てくる小さい警告、しばらく見て見ぬふりしてました。「zsh compinit: insecure directories and files」ってやつです。実害があるわけでもないし、と放置してたんですが、ある日ちょっと腰を据えて調べてみたら、原因は何年も前にインストールしたnodebrewの権限設定だと判明した話です。
compauditで正体を突き止める
まずは正体調べです。こういう時はまずcompauditコマンドで、怪しいディレクトリを洗い出すところから。実行してみると、/usr/local/share/zsh配下のディレクトリが引っかかってました。nodebrewをインストールした時に、npmパッケージのzsh補完機能用として作られたディレクトリです。
実際に毎回出ていた警告はこんな感じでした。

ここに落とし穴がありました。ls -ldで権限を確認すると、グループ書き込み可能な状態になっていました。よくある話です。ここまでは「あーグループ書き込み権限が緩いのか」で済む話なんですが、よく見ると所有者の欄に見覚えのない名前が入っていました。hirabayashifamilyという、Macを初期セットアップした当時に使っていた旧ユーザーアカウントの名残です。つまり2021年頃にnodebrewを入れた時のまま、所有者が何年も置き去りになっていたということでした。
権限を直しただけでは終わらなかった
結果はハズレでした。「じゃあchmodで権限を絞れば解決」と思ってchmod -R go-wを実行したんですが、警告は消えませんでした。ここで一瞬「あれ、直したはずなのに」とやさぐれた気持ちになったんですが、よく考えたら権限(パーミッション)と所有者(オーナー)は別のレイヤーの話でした。所有者が自分以外のままだと、いくら権限を絞ってもzsh側は「安全とは言えない」と判断し続けるようです。
本命はここでした。chownで所有者を今のログインユーザーに変更して、ようやく警告が消えました。まだ続きがありました。ただしこれで終わりではなく、対象のディレクトリの中にシンボリックリンクが混ざっていて、リンク先の実体ファイルの所有者は別途直す必要がありました。権限を1回直して終わり、と思っていたところに二段オチが来た格好です。
放置してるとじわじわ実害に化ける
要注意な点があります。今回は警告だけで実害はなかったんですが、調べる過程で「これを無視してnで毎回スキップし続けていると、そのうちcompdef: command not foundのような別のエラーにつながることがある」という情報にも行き着きました。見た目は地味な警告でも、根っこの設定がズレているサインだったわけです。
まとめ
教訓はこれです。何年も前にインストールしたツールの初期設定が、気づかないまま残り続けて、ある日ふとした拍子に顔を出す。今回は権限を直せば終わりだと思い込んでいたところに、所有者というもう一段の視点が必要でした。地味な警告ほど、放置せずに一度ちゃんとcompauditで潰しておくのが良さそうです。
この記事が参考になったら、応援クリックをお願いします




