【RHEL9.6/rsyslog】ログの権限設定方法
どうも!新人エンジニアの前歯すきっ歯です🦷
「Syslogサーバの運用でログを閲覧・取得するにあたり、OSユーザー(その他のユーザー)がログファイルの読み取り権限のみ持つ設定をしてほしいんだよね~」とご要望がありました。さぁ、どうしましょう!?…ということで、勉強のために検証してみました!
⚙️ 0.本記事について
⚙️ 0-1.問題提起
デフォルト設定のとき、RHELにてrsyslogを通して作成されるログは所有者はroot、ログファイル権限が600で作成されます。 デフォルト設定のままだとその他のユーザーの権限は0のため、Syslogサーバ運用でよくある 「ログの閲覧」や「ログファイルをSCP転送して取得」を行うことができません。 上記運用をするために、その他のユーザーに読み取り権限(=644)を付ける方法を知りたいと感じました!
⚙️ 0-1-1.【補足】デフォルト権限例
以下はrsyslog.confにて/Syslog/syslogtest/syslogtest.logにログを貯めることのみ設定した場合の権限です。 ※権限設定なし
$ ll / | grep Syslog
drwx------ 3 root root 24 Jul 29 07:02 Syslog
$
$ sudo ls -l /Syslog
total 0
drwx------ 2 root root 28 Jul 29 07:02 syslogtest
$
$ sudo ls -l /Syslog/syslogtest
total 8
-rw------- 1 root root 6166 Jul 29 07:19 syslogtest.log
⚙️ 0-2.本記事のゴール
本記事では以下2つの作業を行い各設定のメリデメを明らかにします💪
-
logrotate.d/配下に個別の設定ファイルを作り、ログの権限をローテーション時に変更する。
具体的には、ログローテーション設定ファイル内にcreate 644を記載します。 -
/etc/rsyslog.confの設定を編集して、特定のログファイルの権限を変える。
具体的には、fileCreateMode="0644"などの設定値を追加します。
⚙️ 0-3.実行環境
以下が本記事の実行環境です。
-
AWS EC2上で構築
・AWS EC2:t2.micro/ディスク8GiB/RHEL9.6 -
RHEL内詳細
・rsyslog:8.2412.0-1.el9 (aka 2024.12)
・SELinux無効化済み
※SELinuxが無効化されていないとrsyslog設定やログローテーションが上手くできないです。
⚙️ 0-4.読者に求める知識
Syslogサーバとログローテーションの基礎的な設定値やコマンドの意味の説明は省略します。
この後読み進めて上記の点で悩みがあったときは、Syslogサーバ初心者だった自分が記載した以下記事をご覧ください!Syslogサーバ全般について解説しています。
⚙️ 0-5.本記事の大まかな流れ
本記事の大まかな流れは以下の通りです。
- 結論
- 前提/設定ファイルの設定値について
- logrotate.d/配下の設定ファイルで権限設定
- /etc/rsyslog.confでの権限設定
- おわりに
📜 1.結論
ログの権限を変更する方法とそのメリット・デメリットを先に記載します!
(1)ローテーション設定値で変更する方法(/etc/logrotate.d/配下のファイル)
- メリット:設定箇所が少なく理解しやすい。
- デメリット:ログローテーションしないと権限変更できない。
(2)rsyslog設定値でログファイルの権限を変える方法(rsyslog.conf)
- メリット:各ログの権限が異なる場合でも、1つのファイル内で設定が編集できる。
- デメリット:設定を間違えると意図していないログファイルも権限が変わってしまうため細心の注意が必要。
✔️ 2.前提/rsyslog.confの設定値について
以下rsyslog.confで設定を行ったログファイルにどのように権限を設定するか考えます。
- プライオリティ・ファシリティが
*.info;mail.none;authpriv.none;cron.noneのログを/Syslog/[ホスト名]/[ホスト名].logという名前で格納。 - ホスト名は
syslogtest。 - 上記を反映させたrsyslog.confの設定だと[0-1-1.【補足】デフォルト権限例]で共有したログ権限ディレクトリとファイル名、権限でログファイルが作成される。
- 具体的なrsyslog.confの設定は以下。緑のハイライト部分のみ編集。
※rsyslog.conf内以下記載部分以外はデフォルト設定 - logrotate.d/配下のファイル名は
/etc/logrotate.d/locallogとする。
>template(name="locallog" type="string"
> string="/Syslog/%hostname%/%hostname%.log"
>)
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
>*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog")
🔧 3.logrotate.d/配下の設定ファイルで権限設定
🔧 3-1. /etc/logrotate.d/locallog 設定詳細
以下のログローテーション設定ファイルを作成します。
緑のハイライト部分が権限設定に関わる項目です。
/Syslog/*/*.log
{
#ローテーション周期
daily
#ローテーション世代
rotate 3
#ローテーションしたファイルの圧縮
compress
#ログファイルが空でもローテーションする
ifempty
#指定のログファイルが存在しなくてもエラーを出さずに処理を続行
missingok
#ファイルのタイムスタンプと、ファイル名の日付を一致させる
dateyesterday
> #権限変更
> create 644
#ローテーション後の実行スクリプト設定。rsyslogの再起動を実行。
postrotate
/usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
endscript
}
🔧 3-2. /etc/logrotate.d/locallog 設定方法
以下の順序でログローテーション設定を行います。
#自分がログ保管先として指定した/Syslog配下のログに対して設定する。
#ログローテーションファイルを作成
$ sudo vi /etc/logrotate.d/locallog
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ここで[3-1.設定ファイル詳細]の内容を記載
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
#設定ファイル内容に問題がないか確認する
$ sudo logrotate -d /etc/logrotate.d/locallog
-------------------------
ここでエラーが出なければOK
-------------------------
#デーモンを再起動して設定ファイルを反映させる
$ sudo systemctl daemon-reload
#ログファイルを生成する。
$ logger -p local0.info test
#確認のために強制的にログローテーションを行う。
$ sudo logrotate -f /etc/logrotate.d/locallog
#ローテーションされていることの確認をする。
#以下は「sudo logrotate -f /etc/logrotate.d/locallog」を3回実行した結果
$ sudo ls -l /Syslog/syslogtest
total 204
-rw-r--r-- 1 root root 131121 Jul 29 21:19 syslogtest.log
-rw-r--r-- 1 root root 294 Jul 29 08:39 syslogtest.log.1.gz
-rw-r--r-- 1 root root 295 Jul 29 08:38 syslogtest.log.2.gz
-rw------- 1 root root 1488 Jul 29 08:37 syslogtest.log.3.gz
🔧 3-3. 3章まとめ
✍️ 4./etc/rsyslog.confでの権限設定
✍️ 4-1. 4章の作業前に3章のお掃除
上記作業後、/Syslog/配下は全て削除しました。
また、rsyslogの再起動をして、ログが600の権限で再度溜まり始めたことを確認しました。
本題からは逸れるので、以下プルダウンでの記載に留めます。
リセット作業全容
$ sudo rm -r /Syslog/
$
$ ll / | grep Syslog
$
$ sudo systemctl restart rsyslog
$
$ sudo systemctl status rsyslog
$
$ logger -p local0.info test
$
$ sudo ls -l /Syslog/
total 0
drwx------ 2 root root 28 Jul 30 06:51 syslogtest
$
$ sudo ls -l /Syslog/syslogtest
total 4
-rw------- 1 root root 1547 Jul 30 06:53 syslogtest.log
✍️ 4-2. /etc/rsyslog.conf 設定詳細
以下緑のハイライト部分が[2.前提]設定でお伝えした設定ファイルへ追記・変更した場所です。
設定内容の意味や意図は5章で解説します!
…(略)…
template(name="locllog" type="string"
string="/Syslog/%hostname%/%hostname%.log"
)
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
># rsyslog.serviceのumask値を上書きする
>$umask 0022
>*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog" fileCreateMode="0644")
># 以後のログ権限を/usr/lib/systemd/system/rsyslog.serviceと同じUMask0600に戻す
>$FileCreateMode 0600
# The authpriv file has restricted access.
authpriv.* /var/log/secure
…(略)…
✍️ 4-3. /etc/rsyslog.conf 設定方法
以下の方法で/etc/rsyslog.confを編集していきます。
##rsyslog.confを編集する
$ sudo vi /etc/rsyslog.conf
##rsyslog.confに問題がないかチェックする。
$ rsyslogd -N1
rsyslogd: version 8.2412.0-1.el9, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
##新しくファイルが作られたときに権限が変わるので1度ファイル・ディレクトリを削除する。
##/var/log/secureは`600`で作成されることを同時に確認するため削除
$ sudo rm /var/log/secure
##/Syslog配下のログファイルは権限を`644`に変更するため削除
$ sudo rm -r /Syslog
##何も表示されず各ファイルとディレクトリが削除できたことを確認する。
$ ll /var/log/ | grep secure
$
$ ll / | grep Syslog
##rsyslog.confの設定を反映させるためにrsyslogを再起動する。
$ sudo systemctl restart rsyslog
##rsyslogが正常に動いていること、エラーがないことを確認する。
$ sudo systemctl status rsyslog
##/var/log/secureは権限`600`で作成されたことを確認する。
$ ll /var/log/ | grep secure
-rw------- 1 root root 693 Aug 2 05:40 secure
##/Syslog/syslogtest/syslogtest.logは権限`644`で作成されたことを確認する。
$ sudo ls -l /Syslog/syslogtest
total 4
-rw-r--r-- 1 root root 832 Aug 2 05:45 syslogtest.log
🔖 5./etc/rsyslog.conf設定値解説
🔖 5-1. $umask 0022の必要性
🔖 5-1-1. $umasku 0022とは
$umask 0022は一般的なumaskコマンドと同じでデフォルトで作成されるファイルの権限を引き下げる設定です。これはryslogサービス自体のumask値を上書きさせるために記載しています。
4-3ではなぜそのような対応が必要なのか記載していきます!!
(🔗参考リンク:【rsyslog公式】$umask)
🔖 5-1-2. rsyslogサービス自体のumaskとファイルの権限
$umask 0022記載の話の前提として、実はrsyslogサービス自体のumaskが存在します。
rsyslogの動きを設定している /usr/lib/systemd/system/rsyslog.serviceというファイル内にUMask=0066という項目があります。 ※[Service]セクション5行目参照
[Unit]
Description=System Logging Service
;Requires=syslog.socket
Wants=network.target network-online.target
After=network.target network-online.target
Documentation=man:rsyslogd(8)
Documentation=https://www.rsyslog.com/doc/
[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS
ExecReload=/usr/bin/kill -HUP $MAINPID
UMask=0066
StandardOutput=null
Restart=on-failure
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=net
NoNewPrivileges=yes
ProtectControlGroups=yes
ProtectHome=read-only
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=~@clock @debug @module @raw-io @reboot @swap @cpu-emulation @obsolete
LockPersonality=yes
MemoryDenyWriteExecute=yes
# Increase the default a bit in order to allow many simultaneous
# files to be monitored, we might need a lot of fds.
LimitNOFILE=16384
[Install]
WantedBy=multi-user.target
通常、RHELでファイルを作成した時のデフォルトの権限は644です。基本権限666から
デフォルトumask値022を引くと権限は644になるからです。
しかし、rsyslogサービスとしては上記UMask=0066があるため、基本権限666からrsyslogのデフォルトumask値066を引きファイルの権限が600となります。これが[0-1-1.【補足】デフォルト権限例]でファイルの権限が600となる理由です。
標準ユーザー または root ユーザー が新しい ファイル を作成すると、umask は 022 (rwxr-xr-x) に設定され、ファイルの基本権限は 666 (rw-rw-rw-) に設定されます。これにより、デフォルトのパーミッションは 644 (-rw-r—r--) になりました。(🔗参考リンク:RHEL 11.1.3. デフォルトのファイル権限)
🔖 5-1-3. rsyslogサービス自体のumaskを無効化する方法
前提として、ファイル権限を指定してもumask値の方が優先される仕様となっています。したがって、rsyslogサービス自体のUMask=0066が有効だとグループとその他のユーザーの権限は基本権限6から6を引かれて0となってしまい、rsyslog.confでファイルの権限を644指定してもグループとその他のユーザーの権限は0となってしまいます。
※本記事では記載しませんが、上記自分は実際に試して確認してみました。気になる方はご自分で実践してみてください。
上記から、rsyslogを用いたログファイル生成にて意図した権限にするためには以下どちらかの方法で対応する必要があります。
- rsyslogサービスの
UMask=0066の無効化して、意図した権限がファイルに与えられる状況にする。 - rsyslog.conf内$umaskでrsyslogサービスの
UMask=0066値を上書き(=無効化)してから、意図した指定の権限がファイルに与えられる状況にする。
上記1で対応した場合、意図していないログファイルまで全てのログの権限が変わってしまうので、本記事では上記2で対応しています。それゆえに、rsyslog.coonfに$umask 0022を記載しています。
※$umask 0022を記載すれば、基本権限666から引かれた結果、作成されるファイルの権限は644となり、その他のユーザーの権限が4となる。
🔖 5-1-4. 【おまけ】rsyslogサービスのUMask=0066を無効化した話
本記事の本題とはずれますが、自分は己の目で見て確かめたく、上記実践してみました!
同じような気持ちの方もいるかと想定し(?)、以下に/var/log/secureの権限が644で作成される様子を記載します。
■前提
[2.前提/rsyslog.confの設定値について]で紹介した以下権限の指定をしていないrsyslog.confを使う。
…(略)…
>template(name="locllog" type="string"
> string="/Syslog/%hostname%/%hostname%.log"
>)
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
>*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog")
# The authpriv file has restricted access.
authpriv.* /var/log/secure
…(略)…
■設定作業と/var/log/secureが644で作成される様子
##デフォルトのログは`600`で作成される
##rsyslogサービスの`UMask=0066`が有効化されている状態
$ ll /var/log | grep secure
-rw------- 1 root root 693 Jul 31 08:38 secure
##新しくファイルが作られたときに権限が変わるので1度/var/log/secureを削除する。
$ sudo rm /var/log/secure
##/var/log/secureがなくなったことを確認する。
$ ll /var/log | grep secure
##rsyslogサービスの`UMask=0066`をコメントアウトして無効化する。
$ sudo vi /usr/lib/systemd/system/rsyslog.service
-----------------------
…(略)…
#UMask=0066
…(略)…
-----------------------
##設定を反映させるためにデーモンを再起動する。
$ sudo systemctl daemon-reload
##rsyslogが新しいファイルへログを書き込むためにrsyslogも再起動する。
##/etc/loglotate.d/locallogに以下コマンドを書く理由と同じ。
##/usr/bin/systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
$ sudo systemctl restart rsyslog
##rsyslogに問題がないことを確認する。
$ sudo systemctl status rsyslog
##/var/log/secureに何かしらのログを書き込みたくて再起動
$ sudo reboot
##/var/log/secureの権限が`644`で作成されたことを確認する。
$ ll /var/log | grep secure
-rw-r--r-- 1 root root 950 Jul 31 08:47 secure
🔖 5-2. fileCreateModeでの権限指定
🔖 5-2-1. $fileCreateModeとは
$fileCreateModeはログを指定した権限で作成する設定です。 本記事ではログ保管するファイルの権限のみを考えるので、特殊ビット(1番左の桁の0。setuid,setgid,sticky bitと呼ばれる部分)は考慮外とします。以後、2つ設定した$fileCreateModeの意図をお伝えします。
(🔗参考リンク:【rsyslog公式】FileCreateMode)
🔖 5-2-2. action(~略~ fileCreateMode="0644")の意図
まず前提として、[5-1-3. rsyslogサービス自体のumaskを無効化する方法]の最後でもお伝えしたように、$umask 0022があればfileCreateMode="0644"を設定しなくても*.info;mail.none;authpriv.none;cron.noneのログは644の権限で作成されます。(本記事で記載しませんが、自分は試してみました。)
その上で、fileCreateMode="0644"記載の意図は「将来的にrsyslog.confが編集され記載内容の順序が変わったとしても、ログの権限が644で作成されるようにするため」です。
例えば、以下設定値のようにaction(~略~ fileCreateMode="0644")のfileCreateMode="0644"を削除した行がrsyslog.coong内で$FileCreateMode 0600より下の行に書かれた場合、ログのファイルの権限は600で作成されてしまいます。
…(略)…
template(name="locllog" type="string"
string="/Syslog/%hostname%/%hostname%.log"
)
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
># rsyslog.serviceのumask値を上書きする
>$umask 0022
-------------
何かしらの変更があり、設定値のこの付近を編集するイメージ
-------------
># 以後のログ権限を/usr/lib/systemd/system/rsyslog.serviceと同じUMask0600に戻す
>$FileCreateMode 0600
<### fileCreateMode="0644"なしのログ設定
<### ログの権限は上記"$FileCreateMode 0600"により"0600"で作成される
<*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog")
# The authpriv file has restricted access.
authpriv.* /var/log/secure
…(略)…
上記のようなことがないように、rsyslog.confが編集され記載内容の順序が変わったとしてもログの権限が644で作成される設定としています。
🔖 5-2-3. $FileCreateMode 0600の意図
$FileCreateMode 0600記載の意図は「rsyslogサービス自体のumask設定と同じ値に戻すため」です。 この設定をしないと$umask 0022が適用されたままなので、/var/log/secureなど*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog" fileCreateMode="0644")記載以降のログも全て644の権限となってしまいます。
そのため、*.info;mail.none;authpriv.none;cron.noneのログのみを644で作成し、その他のログはrsyslogサービス自体のumask設定と同じ値600で作成できる設定としています。
🔖 5-3. 【2025/12追記】dirCreateModeでの権限設定
本記事を記載した時にディレクトリの権限指定を忘れていたので、以下に追記していきます!
🔖 5-3-1. デフォルトのディレクトリ権限(再掲)
前提として、[0-1-1.【補足】デフォルト権限例]で記載しているように、デフォルトでディレクトリ権限は700で作成されます。
$ ll / | grep Syslog
drwx------ 3 root root 24 Jul 29 07:02 Syslog
$ sudo ls -l /Syslog
total 0
drwx------ 2 root root 28 Jul 29 07:02 syslogtest
🔖 5-3-2. dirCreateModeとは
dirCreateModeはディレクトリを指定した権限で作成する設定です。
(🔗参考リンク:【rsyslog公式】dirCreateMode)
以下のようにdirCreateMode="0755"を追記することで、fileCreateMode="0644"同様にディレクトリ権限を指定可能です!
…(略)…
template(name="locllog" type="string"
string="/Syslog/%hostname%/%hostname%.log"
)
#### RULES ####
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
># rsyslog.serviceのumask値を上書きする
>$umask 0022
>*.info;mail.none;authpriv.none;cron.none action(type="omfile" dynaFile="locallog" fileCreateMode="0644" dirCreateMode="0755")
># 以後のログ権限を/usr/lib/systemd/system/rsyslog.serviceと同じUMask0600に戻す
>$FileCreateMode 0600
# The authpriv file has restricted access.
authpriv.* /var/log/secure
…(略)…
上記設定値でログを出力してみると、ディレクトリの権限が755で作成されていることが確認できました!
### /Syslogの権限が755であることを確認する。
$ ls -l / ###表示結果抜粋
drwxr-xr-x 3 root root 24 Sep 13 08:00 Syslog
### /Syslog/syslogtestの権限が755であることを確認する。
$ ls -l /Syslog
total 0
drwxr-xr-x 2 root root 130 Sep 18 07:29 syslogtest
### 念のためにログファイルの権限が644であることを確認する。
$ ls -l /Syslog/syslogtest/
total 168
-rw-r--r-- 1 root root 144814 Sep 18 13:54 syslogtest.log
-rw-r--r-- 1 root root 5641 Sep 13 23:58 syslogtest.log-20250913.gz
-rw-r--r-- 1 root root 6563 Sep 14 23:58 syslogtest.log-20250914.gz
-rw-r--r-- 1 root root 6840 Sep 15 20:22 syslogtest.log-20250917.gz
🔖 5-4. 5章まとめ
🔚 6.おわりに
ここまでご覧いただいて、読者の皆さんには[1.結論]で記載した以下メリット・デメリットの意味を理解していただけたでしょうか…?
(1)ローテーション設定値で変更する方法(/etc/logrotate.d/配下のファイル)
- メリット:設定箇所が少なく理解しやすい。
- デメリット:ログローテーションしないと権限変更できない。
(2)rsyslog設定値でログファイルの権限を変える方法(rsyslog.conf)
- メリット:各ログの権限が異なる場合でも、1つのファイル内で設定が編集できる。
- デメリット:設定を間違えると意図していないログファイルも権限が変わってしまうため細心の注意が必要。
他にもSyslogサーバでの権限変更方法をご存知の方がいればコメントで教えてくださると嬉しいです!
Discussion