メタデータの参照元プロセスをAuditdで確認する

メタデータの参照元プロセスをAuditdで確認する

EFSでのメタデータ読み込みが気になるけど誰が犯人なのか特定できていない方へ。
#Amazon EFS
#Amazon EC2
#Amazon Linux 2023
#AWS
なおにし

なおにし

facebook logohatena logotwitter logo
Clock Icon2025.03.07

こんにちは、なおにしです。

EFSに保存されているファイルのメタデータにアクセスしたプロセスをAuditdで特定する機会がありましたのでご紹介します。

はじめに

ファイルシステムに保存されているファイルへのアクセスでは、大きく分けてファイルそのもの(コンテンツ)に対するアクセス(Read/Writeなど)と、ファイルのメタデータに対するアクセスがあります。
プログラムからファイルそのものにアクセスする際は「Open→Read/Write→Close」というようなステップが実行されているかと思いますが、例えばlsコマンドを使ってファイル一覧を表示した際は、ファイルのメタデータにアクセスしたという形になります。

では、ファイルのメタデータに対するアクセスではReadのIOが発生しないのかというと、もちろん発生しています。具体的に何byteの読み込みが発生するのかはファイルシステムに依りますが、EFSをNFSマウントした環境であれば以下の記事をご参照ください。

https://dev.classmethod.jp/articles/amazon-efs-metadata-size/

上記の記事に記載のとおり、EFS上でメタデータの読み込みが大量に発生している状況だと、EFSをElastic Throughputモードで使用している場合は想定外の料金が発生する可能性があります。一方で、EFSをBurst Throughputモードで使用している場合は、想定外に早くクレジットが枯渇してしまい、パフォーマンスがベースラインスループットに制限されてしまう可能性があります。Burst Throughputモードについては以下の記事もご参照ください。

https://dev.classmethod.jp/articles/benchmark-ebs-efs-with-fio/

このようにメタデータの読み込み処理は特にEFSにファイルを格納している状況では注意が必要ですが、状況によってはどのプロセスがメタデータの読み込み処理を行っているのか判断がつかないこともあるかもしれません。

そこで、実際にEFSにアクセスしたプロセスをAuditdを使用して特定してみます。Auditdについては以下をご参照ください。

https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/9/html/security_hardening/auditing-the-system_security-hardening

なお、事前にメタデータの読み込み元プロセスを特定するためにいくつかのツールを試してみたのですが、メタデータアクセスで使用されるstat 系のシステムコールを捕捉することが難しいそうだったため、今回はAuditdを使用しています。

やってみた

事前準備

検証環境は上記の記事と同じなのでそのまま引用させていただきました。EC2インスタンスからEFSファイルシステムをNFSでマウントしているだけです。

20250307_naonishi_efs-metadata-auditd-check_1

AL2023にamazon-efs-utils パッケージをインストールの上、以下のとおりEFSをマウントしています。

# mount -t efs -o tls fs-0fc99de29a9a213be:/ /mnt/efs
# df -h
Filesystem        Size  Used Avail Use% Mounted on
（略）
127.0.0.1:/       8.0E     0  8.0E   0% /mnt/efs

テキストファイルを配置します。

# echo "テストです" > /mnt/efs/test.txt
# cat /mnt/efs/test.txt 
テストです

AL2023では既にAuditdはインストールされていてサービスも有効状態でした。

# systemctl status auditd.service 
● auditd.service - Security Auditing Service
     Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-03-06 07:09:41 UTC; 3h 24min ago
       Docs: man:auditd(8)
             https://github.com/linux-audit/audit-documentation
   Main PID: 1289 (auditd)
      Tasks: 2 (limit: 2255)
     Memory: 2.8M
        CPU: 105ms
     CGroup: /system.slice/auditd.service
             └─1289 /sbin/auditd

Mar 06 07:09:40 ip-172-30-0-231.ap-northeast-1.compute.internal systemd[1]: Starting auditd.service - Security Auditing Service...
Mar 06 07:09:40 ip-172-30-0-231.ap-northeast-1.compute.internal auditd[1289]: No plugins found, not dispatching events
Mar 06 07:09:40 ip-172-30-0-231.ap-northeast-1.compute.internal auditd[1289]: Init complete, auditd 3.0.6 listening for events (startup state enable)
Mar 06 07:09:41 ip-172-30-0-231.ap-northeast-1.compute.internal augenrules[1293]: /sbin/augenrules: No change
Mar 06 07:09:41 ip-172-30-0-231.ap-northeast-1.compute.internal augenrules[1343]: No rules
Mar 06 07:09:41 ip-172-30-0-231.ap-northeast-1.compute.internal systemd[1]: Started auditd.service - Security Auditing Service.

既存ルールを確認してみます。

# auditctl -l
-a never,task

一つだけ登録されていました。こちらの読み方はauditctlのmanページに基づくと以下のとおりです。

  • 「-a」はルールの追加に使用され、「-a [list,action|action,list]」の形式で指定します
  • 「never」は監査レコードを作成しないというアクションです
  • 「task」は新しいタスク(プロセス)がシステムコールによって作成される時に使用されるリストです

したがって、「システムコールによるプロセス作成イベントを監査ログに記録しない」というルールになるかと思います。今回、こちらのルールが残ったままでは以降の手順に支障が出る(メタデータの読み込みを検出できない)ため、一旦削除します。

# auditctl -d never,task
# auditctl -l
No rules

なお、今回実施しているコマンドによるAuditdのルール追加・削除は一時的な設定ですので、以下の手順で元に戻すことが可能です。

# augenrules --load
/usr/sbin/augenrules: No change
No rules
# auditctl -l
-a never,task

AL2023では手動によるAuditdのサービス再起動は制限されているようなので、サービス再起動による反映(設定戻し)はできないことにご注意ください。

# systemctl restart auditd.service 
Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status auditd.service' for details.

全てのシステムコールを記録する

それでは、作成したテキストファイルに対して実行された全てのシステムコールを記録するルールを設定してみます。

# auditctl -a always,exit -S all -F path=/mnt/efs/test.txt -k file_metadata_access
# auditctl -l
-a always,exit -S all -F path=/mnt/efs/test.txt -F key=file_metadata_access

作成したルールについて補足します。まず、「action,list」を「always,exit」で指定しています。こちらの内容は以下のとおりです。

  • 「always」は常にシステムコールの開始時に記録を行い、システムコールの終了時に常にレコードを書き出すアクションです
  • 「exit」はシステムコールの終了時に監査イベントを作成するかどうかを決定するリストです

したがって、「指定されたシステムコールが終了する際に常に監査ログを記録する」というルールになります。
そこで、「 -S all」を指定することで全てのシステムコールを対象としています。また、keyで指定している内容は、後ほど検出結果を絞り込むためのフィルタ用文字列です。

それでは実際に確認してみます。検出結果はausearchコマンドで確認できます。

### lsコマンドによる参照前
# ausearch -k file_metadata_access
----
time->Thu Mar  6 11:15:17 2025
type=CONFIG_CHANGE msg=audit(1741259717.079:801): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access" list=4 res=1

# ls -l /mnt/efs/
total 4
-rw-r--r--. 1 root root 16 Mar  6 11:33 test.txt

### lsコマンドによる参照後
# ausearch -k file_metadata_access
----
time->Thu Mar  6 11:15:17 2025
type=CONFIG_CHANGE msg=audit(1741259717.079:801): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access" list=4 res=1
----
time->Thu Mar  6 11:34:44 2025
type=PROCTITLE msg=audit(1741260884.470:841): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6D6E742F6566732F
type=PATH msg=audit(1741260884.470:841): item=0 name="/mnt/efs/test.txt" inode=14088948032602146935 dev=00:31 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:nfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741260884.470:841): cwd="/root"
type=SYSCALL msg=audit(1741260884.470:841): arch=c000003e syscall=332 success=yes exit=0 a0=ffffff9c a1=7ffc657974f0 a2=100 a3=25e items=1 ppid=42293 pid=51682 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295 comm="ls" exe="/usr/bin/ls" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"
----
time->Thu Mar  6 11:34:44 2025
type=PROCTITLE msg=audit(1741260884.470:842): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6D6E742F6566732F
type=PATH msg=audit(1741260884.470:842): item=0 name="/mnt/efs/test.txt" inode=14088948032602146935 dev=00:31 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:nfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741260884.470:842): cwd="/root"
type=SYSCALL msg=audit(1741260884.470:842): arch=c000003e syscall=191 success=no exit=-95 a0=7ffc657974f0 a1=7efc4c78c05a a2=7ffc657974b0 a3=18 items=1 ppid=42293 pid=51682 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295 comm="ls" exe="/usr/bin/ls" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"
----
time->Thu Mar  6 11:34:44 2025
type=PROCTITLE msg=audit(1741260884.470:843): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6D6E742F6566732F
type=PATH msg=audit(1741260884.470:843): item=0 name="/mnt/efs/test.txt" inode=14088948032602146935 dev=00:31 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:nfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741260884.470:843): cwd="/root"
type=SYSCALL msg=audit(1741260884.470:843): arch=c000003e syscall=192 success=yes exit=27 a0=7ffc657974f0 a1=7efc4c7b1251 a2=55663b1b0e80 a3=ff items=1 ppid=42293 pid=51682 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=4294967295 comm="ls" exe="/usr/bin/ls" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"

lsコマンドで参照されるだけでかなりのログが出力されていることがわかります。長いので見づらいですが、いずれも「pid=51682」や「exe="/usr/bin/ls"」という記載があって参照元を特定できそうです。

また、lsコマンドによって対象ファイルが参照されたことで出力された3レコードのログについて、それぞれシステムコールに関して以下の記載があります。

  • syscall=332
  • syscall=191
  • syscall=192

上記がファイルのメタデータを参照した際に呼び出されたシステムコール番号になります。番号からシステムコール名を取得するには以下のようにausyscallコマンドを利用できます。

# ausyscall 332
statx
# ausyscall 191
getxattr
# ausyscall 192
lgetxattr

システムコール名が判明すれば、あとはその内容などはmanコマンドで確認することもできますが、Webで公開されているmanページからも確認できます。例えばstatxについては以下のとおりです。

https://man7.org/linux/man-pages/man2/statx.2.html

特定のシステムコールを記録する

それではstatxを対象に再度監査ログを出力してみます。以下のように指定します。

# auditctl -a always,exit -F arch=b64 -S statx -F path=/mnt/efs/test.txt -k file_metadata_access_statx
# auditctl -l
-a always,exit -F arch=b64 -S statx -F path=/mnt/efs/test.txt -F key=file_metadata_access_statx

「-F arch=b64」によってCPUアーキテクチャを追加した理由は、システムコールを個別に指定する場合はアーキテクチャを指定しないと怒られたためです。

# auditctl -a always,exit -S statx -F path=/mnt/efs/test.txt -k file_metadata_access
WARNING - 32/64 bit syscall mismatch, you should specify an arch

結果は以下のとおりです。

### lsコマンドによる参照前
# ausearch -k file_metadata_access_statx
----
time->Thu Mar  6 12:08:31 2025
type=PROCTITLE msg=audit(1741262911.834:314): proctitle=617564697463746C002D6100616C776179732C65786974002D46006172636800623634002D53007374617478002D460070617468002F6D6E742F6566732F746573742E747874002D6B0066696C655F6D657461646174615F6163636573735F7374617478
type=SYSCALL msg=audit(1741262911.834:314): arch=c000003e syscall=44 success=yes exit=1100 a0=4 a1=7ffe46d509c0 a2=44c a3=0 items=0 ppid=1965 pid=3504 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=CONFIG_CHANGE msg=audit(1741262911.834:314): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access_statx" list=4 res=1

# ls -l /mnt/efs/
total 4
-rw-r--r--. 1 root root 16 Mar  6 11:33 test.txt

### lsコマンドによる参照後
# ausearch -k file_metadata_access_statx
----
time->Thu Mar  6 12:08:31 2025
type=PROCTITLE msg=audit(1741262911.834:314): proctitle=617564697463746C002D6100616C776179732C65786974002D46006172636800623634002D53007374617478002D460070617468002F6D6E742F6566732F746573742E747874002D6B0066696C655F6D657461646174615F6163636573735F7374617478
type=SYSCALL msg=audit(1741262911.834:314): arch=c000003e syscall=44 success=yes exit=1100 a0=4 a1=7ffe46d509c0 a2=44c a3=0 items=0 ppid=1965 pid=3504 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=CONFIG_CHANGE msg=audit(1741262911.834:314): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access_statx" list=4 res=1
----
time->Thu Mar  6 12:10:01 2025
type=PROCTITLE msg=audit(1741263001.494:317): proctitle=6C73002D2D636F6C6F723D6175746F002D6C002F6D6E742F6566732F
type=PATH msg=audit(1741263001.494:317): item=0 name="/mnt/efs/test.txt" inode=14088948032602146935 dev=00:31 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:nfs_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741263001.494:317): cwd="/root"
type=SYSCALL msg=audit(1741263001.494:317): arch=c000003e syscall=332 success=yes exit=0 a0=ffffff9c a1=7ffee1950b80 a2=100 a3=25e items=1 ppid=1965 pid=3664 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="ls" exe="/usr/bin/ls" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access_statx"

statxによるアクセスのみが監査ログに記録されました。

補足

メタデータへのアクセスで使用されるシステムコールは上記だけとは限りませんので、最初からstatxのみをターゲットとして確認することはおすすめできません。

例えばrsyncの場合は以下のとおりでした。

# auditctl -a always,exit -S all -F path=/mnt/efs/test.txt -k file_metadata_access
# ausearch -k file_metadata_access
----
time->Fri Mar  7 02:45:47 2025
type=PROCTITLE msg=audit(1741315547.954:420): proctitle=617564697463746C002D6100616C776179732C65786974002D5300616C6C002D460070617468002F6D6E742F6566732F746573742E747874002D6B0066696C655F6D657461646174615F616363657373
type=SYSCALL msg=audit(1741315547.954:420): arch=c000003e syscall=44 success=yes exit=1096 a0=4 a1=7fff50b97900 a2=448 a3=0 items=0 ppid=25719 pid=26970 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=CONFIG_CHANGE msg=audit(1741315547.954:420): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access" list=4 res=1

# rsync -a --stats /mnt/efs/ /home/ec2-user/
（略）

# cat /home/ec2-user/test.txt 
テストです

# ausearch -k file_metadata_access
----
time->Fri Mar  7 02:45:47 2025
type=PROCTITLE msg=audit(1741315547.954:420): proctitle=617564697463746C002D6100616C776179732C65786974002D5300616C6C002D460070617468002F6D6E742F6566732F746573742E747874002D6B0066696C655F6D657461646174615F616363657373
type=SYSCALL msg=audit(1741315547.954:420): arch=c000003e syscall=44 success=yes exit=1096 a0=4 a1=7fff50b97900 a2=448 a3=0 items=0 ppid=25719 pid=26970 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=CONFIG_CHANGE msg=audit(1741315547.954:420): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access" list=4 res=1
----
time->Fri Mar  7 02:46:11 2025
type=PROCTITLE msg=audit(1741315571.074:423): proctitle=7273796E63002D61002D2D7374617473002F6D6E742F6566732F002F686F6D652F6563322D757365722F
type=PATH msg=audit(1741315571.074:423): item=0 name="test.txt" inode=25167266 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:mnt_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741315571.074:423): cwd="/mnt/efs"
type=SYSCALL msg=audit(1741315571.074:423): arch=c000003e syscall=262 success=yes exit=0 a0=ffffff9c a1=7ffe6837eba0 a2=7ffe6837db10 a3=100 items=1 ppid=25719 pid=27032 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"
----
time->Fri Mar  7 02:46:11 2025
type=PROCTITLE msg=audit(1741315571.084:424): proctitle=7273796E63002D61002D2D7374617473002F6D6E742F6566732F002F686F6D652F6563322D757365722F
type=PATH msg=audit(1741315571.084:424): item=0 name="test.txt" inode=25167266 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:mnt_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741315571.084:424): cwd="/mnt/efs"
type=SYSCALL msg=audit(1741315571.084:424): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7ffe68381f20 a2=20000 a3=0 items=1 ppid=25719 pid=27032 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"

# ausyscall 262
newfstatat

# ausyscall 257
openat

### もう一度rsyncしてみる
# rsync -a --stats /mnt/efs/ /home/ec2-user/
（略）
# ausearch -k file_metadata_access
----
time->Fri Mar  7 02:45:47 2025
type=PROCTITLE msg=audit(1741315547.954:420): proctitle=617564697463746C002D6100616C776179732C65786974002D5300616C6C002D460070617468002F6D6E742F6566732F746573742E747874002D6B0066696C655F6D657461646174615F616363657373
type=SYSCALL msg=audit(1741315547.954:420): arch=c000003e syscall=44 success=yes exit=1096 a0=4 a1=7fff50b97900 a2=448 a3=0 items=0 ppid=25719 pid=26970 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="auditctl" exe="/usr/sbin/auditctl" subj=system_u:system_r:unconfined_service_t:s0 key=(null)
type=CONFIG_CHANGE msg=audit(1741315547.954:420): auid=4294967295 ses=4294967295 subj=system_u:system_r:unconfined_service_t:s0 op=add_rule key="file_metadata_access" list=4 res=1
----
time->Fri Mar  7 02:46:11 2025
type=PROCTITLE msg=audit(1741315571.074:423): proctitle=7273796E63002D61002D2D7374617473002F6D6E742F6566732F002F686F6D652F6563322D757365722F
type=PATH msg=audit(1741315571.074:423): item=0 name="test.txt" inode=25167266 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:mnt_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741315571.074:423): cwd="/mnt/efs"
type=SYSCALL msg=audit(1741315571.074:423): arch=c000003e syscall=262 success=yes exit=0 a0=ffffff9c a1=7ffe6837eba0 a2=7ffe6837db10 a3=100 items=1 ppid=25719 pid=27032 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"
----
time->Fri Mar  7 02:46:11 2025
type=PROCTITLE msg=audit(1741315571.084:424): proctitle=7273796E63002D61002D2D7374617473002F6D6E742F6566732F002F686F6D652F6563322D757365722F
type=PATH msg=audit(1741315571.084:424): item=0 name="test.txt" inode=25167266 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:mnt_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741315571.084:424): cwd="/mnt/efs"
type=SYSCALL msg=audit(1741315571.084:424): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=7ffe68381f20 a2=20000 a3=0 items=1 ppid=25719 pid=27032 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"
----
time->Fri Mar  7 02:48:03 2025
type=PROCTITLE msg=audit(1741315683.874:427): proctitle=7273796E63002D61002D2D7374617473002F6D6E742F6566732F002F686F6D652F6563322D757365722F
type=PATH msg=audit(1741315683.874:427): item=0 name="test.txt" inode=25167266 dev=103:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:mnt_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1741315683.874:427): cwd="/mnt/efs"
type=SYSCALL msg=audit(1741315683.874:427): arch=c000003e syscall=262 success=yes exit=0 a0=ffffff9c a1=7ffc308c61a0 a2=7ffc308c5110 a3=100 items=1 ppid=25719 pid=27121 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4294967295 comm="rsync" exe="/usr/bin/rsync" subj=system_u:system_r:unconfined_service_t:s0 key="file_metadata_access"

初回の同期ではnewfstatatとopenatのシステムコールが呼ばれています。同期先にテストファイルが存在しなかったので、openatによって元ファイルが開かれた形になります。ですが2回目の同期では同期先にテストファイルが存在するので、メタデータアクセスのnewfstatatしか呼ばれていないようです。いずれにしても、statxは監査ログに記録されておりません。

まとめ

正直やってみた内容自体は別にEFSにテキストファイルを配置して行う必要はないものだったのですが、主旨としてはEFSでメタデータの読み込み元が気になった時に思い出したい内容だったのでEFSの記事という扱いにしました。

本記事がどなたかのお役に立てれば幸いです。

参考

Share this article

facebook logohatena logotwitter logo

関連記事

วิธีการย้ายข้อมูลของ Amazon Elastic File System(EFS) ไปยัง Region อื่น ด้วย AWS DataSync

วิธีการย้ายข้อมูลของ Amazon Elastic File System(EFS) ไปยัง Region อื่น ด้วย AWS DataSync

Amazon EFSで読み取りコストが増加したので、CloudWatchメトリクスで原因調査してみた

Amazon EFSで読み取りコストが増加したので、CloudWatchメトリクスで原因調査してみた

User avatar
おつまみ
2025.01.27
複数のAWS LambdaにAmazon EFSやAmazon S3などの共有ストレージを設定するワークショップに参加してきた #AWSreInvent

複数のAWS LambdaにAmazon EFSやAmazon S3などの共有ストレージを設定するワークショップに参加してきた #AWSreInvent

User avatar
おのやん
2024.12.04
[アップデート] Amazon EFSのElastic Throughputで最大250万読み取りIOPSと最大50万書き込みIOPSをサポートしました

[アップデート] Amazon EFSのElastic Throughputで最大250万読み取りIOPSと最大50万書き込みIOPSをサポートしました

User avatar
武田隆志
2024.11.28
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.