ファイル作成時のデフォルトパーミッションを環境に合わせて適切に設定する

Linuxで新しいファイルやディレクトリを作成したとき、そのパーミッションが「なぜこの値になるのか」と感じたことはないでしょうか。その答えが umask（ユーザーファイル作成マスク）です。umask を正しく理解・設定することで、複数ユーザーが共同作業するディレクトリでの権限トラブルや、Webサーバーのファイルを意図せず外部から読み取れる状態にしてしまうリスクを未然に防げます。

まず結論：umask が新規ファイルのパーミッションを決める

新規作成時のパーミッションは、次の計算式で決まります。

• ディレクトリ：最大値 777 − umask 値 ＝ 実際のパーミッション
• ファイル：最大値 666 − umask 値 ＝ 実際のパーミッション

多くのディストリビューションにおけるデフォルト値 0022 を当てはめると、ディレクトリは 755（rwxr-xr-x）、ファイルは 644（rw-r--r--）になります。現在の設定は以下で確認できます。

umask
# 出力例: 0022

umask -S
# シンボル表記で確認: u=rwx,g=rx,o=rx

先頭の 0 は setuid / setgid / sticky ビットのプレースホルダーです。通常はここを変更する必要はありません。

umask 値とパーミッションの対応表

よく使う umask 値を整理すると次のとおりです。

umask	ファイル（666 から）	ディレクトリ（777 から）	典型的な用途
0022	644（rw-r–r–）	755（rwxr-xr-x）	一般ユーザー・公開 Web コンテンツ
0002	664（rw-rw-r–）	775（rwxrwxr-x）	グループ共同作業ディレクトリ
0027	640（rw-r—–）	750（rwxr-x—）	機密情報・本番アプリ設定ファイル
0077	600（rw——-）	700（rwx——）	SSH 秘密鍵・個人の証明書

重要な注意点として、umask はビットごとの AND NOT 演算（引き算の近似）であるため、実行権限（x）がファイルに付くことはありません。umask を 0000 にしても、通常ファイルの初期パーミッションは 666 が上限です。

umask をセッション内で一時的に変更する

現在のシェルセッションのみ変更したい場合は、引数に値を渡すだけです。ログアウトかシェル終了でリセットされるため、スクリプト内や一時的な作業に向いています。

# グループ書き込みを許可する設定に変更
umask 0002

# 動作を確認する
mkdir testdir && ls -ld testdir
# drwxrwxr-x 2 user group 4096 ... testdir/

touch testfile && ls -l testfile
# -rw-rw-r-- 1 user group 0 ... testfile

umask 設定を永続化する方法

特定ユーザーだけに適用する

~/.bashrc（インタラクティブシェル）または ~/.bash_profile（ログインシェル）に追記します。

echo 'umask 0002' >> ~/.bashrc
source ~/.bashrc

システム全体に適用する

現代のディストリビューションでは /etc/profile を直接編集するより、/etc/profile.d/ 以下に専用ファイルを作成する方法が推奨されます。パッケージ更新で /etc/profile が上書きされても影響を受けません。

sudo tee /etc/profile.d/custom-umask.sh <<'EOF'
umask 0022
EOF
sudo chmod 644 /etc/profile.d/custom-umask.sh

systemd サービスに適用する

デーモンプロセスはシェルの umask を継承しないことがあります。systemd で管理するサービスには、ユニットファイルの [Service] セクションで UMask= を直接指定します。既存サービスの設定を変えたい場合はドロップインファイルを使うと、本体のユニットファイルを汚さずに済みます。

# 例：nginx の umask だけを上書きするドロップイン
sudo systemctl edit nginx

エディタが開いたら以下を追記して保存します。

[Service]
UMask=0022

sudo systemctl daemon-reload
sudo systemctl restart nginx

実務で踏みやすい落とし穴

計算が直感と合わない場合がある：umask 0033 を 666 から引くと 633 になりそうですが、実際には 644 になります。ビットごとに計算するため「引いて負になるビットは 0 にクリアされる」動作があるためです。複雑な値を設定するときは、実際にファイルを作成して ls -l で確認するのが確実です。

グループ共有には umask だけでは不十分な場合がある：あるファイルサーバーの運用現場では、umask を 0002 に設定したにもかかわらず、グループメンバーが作成したファイルを他のメンバーが編集できないトラブルが発生しました。原因は、作成者のプライマリグループが共有グループと異なっていたことです。共有ディレクトリに setgid ビット（g+s）を設定することで、配下のファイルが自動的に親ディレクトリのグループを継承するようになります。

chmod g+s /shared/project
ls -ld /shared/project
# drwxrwsr-x ... /shared/project

sudo 経由での作業では umask が変わる：sudo で実行したコマンドは呼び出し元のユーザー umask を引き継ぎません。sudo -s や sudo bash でルートシェルに入った場合は、root の umask（多くの環境で 0022）が適用されます。スクリプト内で sudo を使いながら特定のパーミッションを保証したい場合は、install -m 644 や chmod で明示的に設定する方が確実です。