☰

ACL

tag-icon • tag-icon files rm group
ACL

サービスが中断された後に残ったいくつかのジャンク共有メモリファイルをクリーンアップしようとしています。サービスはシステムユーザーと特定のグループで実行されます。私はグループのメンバーですが、共有メモリを削除することはできません。

$ ls -la /dev/shm
drwxrwxrwt  2 root   root        600 Jun 20 11:18 .
drwxr-xr-x 22 root   root       3680 Jun 19 12:43 ..
-rw-rw-rw-  1 simbot simusers 500032 Jun 20 10:35 Sim_SharedMem_SLM__data_0

$ groups | grep simusers -q && echo member || echo not member
member

$ rm -f /dev/shm/Sim_SharedMem_SLM__data_0 
rm: cannot remove '/dev/shm/Sim_SharedMem_SLM__data_0': Operation not permitted

ルートとしてファイルを削除するのに問題はありません。私がプロセスを実行（および競合）した場合（ファイルを所有しているユーザー）、ファイルの削除に問題はありません。

産む

問題を実証する最も簡単な方法は、プロセスを直接実行し、一部のジャンクファイルを他のユーザーが所有しているかのように変更することです。

$ /usr/local/bin/badProcess
^C

$ ls -la /dev/shm
drwxrwxrwt  2 root root     640 Jun 20 11:31 .
drwxr-xr-x 22 root root    3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 stew stew  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ sudo chown simbot          Sim_SharedMem_SLM__data_1
$ sudo chown       :simusers Sim_SharedMem_SLM__data_2
$ sudo chown simbot:simusers Sim_SharedMem_SLM__data_3

$ ls -la /dev/shm
drwxrwxrwt  2 root   root         640 Jun 20 11:31 .
drwxr-xr-x 22 root   root        3680 Jun 19 12:43 ..
-rw-rw-rw-  1 stew   stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_0
-rw-rw-rw-  1 simbot stew      500032 Jun 20 11:31 Sim_SharedMem_SLM__data_1
-rw-rw-rw-  1 stew   simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_2
-rw-rw-rw-  1 simbot simusers  500032 Jun 20 11:31 Sim_SharedMem_SLM__data_3

$ rm /dev/shm/*
rm: cannot remove 'Sim_SharedMem_SLM__data_1`': Operation not permitted
rm: cannot remove 'Sim_SharedMem_SLM__data_3`': Operation not permitted

lsattr

いくつかのソリューション+a または +i 属性を確認するには、lsattr を使用することをお勧めします。

$ lsattr Sim_SharedMem_SLM__data_0
lsattr: Inappropriate ioctl for device While reading flags on Sim_SharedMem_SLM__data_0

そのようなことが起こるでしょうtmpfsはこれらの属性をサポートしていないため（ディレクトリです）

$ mount | grep /dev/shm
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)

ACL

親ディレクトリまたはファイル自体に奇妙な点があるかどうかを確認するためにACLを見ました。私の考えでは、私たちはこれからls 学んだことがないようです。親ディレクトリへの書き込み権限

$ getfacl /dev/shm
getfacl: Removing leading '/' from absolute path names
# file: dev/shm
# owner: root
# group: root
# flags: --t
user::rwx
group::rwx
other::rwx

$ getfacl /dev/shm/Sim_SharedMem_SLM__data_0 
getfacl: Removing leading '/' from absolute path names
# file: dev/shm/Sim_SharedMem_SLM__data_0
# owner: simbot
# group: simusers
user::rw-
group::rw-
other::rw-

答え1

ファイルを削除する際に重要なのは、ファイル権限ではなく、ファイルが置かれているディレクトリの権限です。

あなたの場合、誰もがディレクトリへの書き込み権限を持っていますが、ディレクトリには「固定ビット」セット（t権限文字列の末尾）もあります。

これらのディレクトリでは、ファイルの削除は異なる動作をするため、次のようにする必要があります。所有者ファイルの所有者、固定ディレクトリの所有者、またはファイルを削除できるルート。

sticky(8)以下はOpenBSDシステムのマニュアルです：

スティッキーディレクトリ

「固定ビット」が設定されたディレクトリは、ファイルの削除に制限があります。ユーザーは、ディレクトリへの書き込み権限があり、ファイル所有者、ディレクトリ所有者、またはスーパーユーザーである場合にのみ、固定ディレクトリ内のファイルを削除または名前変更できます。。この機能は/tmp公に書き込み可能でなければなりませんが、ユーザーが互いのファイルをランダムに削除したり名前を変更したりする権限を拒否する必要があるディレクトリに効果的に適用できます。

Ubuntuでは、chmod(1)マニュアルには同じ情報があります。

制限除去フラグまたは固定ビット

制限された除去フラグまたは固定ビットは、ファイル形式によって解釈が異なる単一ビットである。 ディレクトリの場合、権限のないユーザーがファイルまたはディレクトリを所有していない限り、ディレクトリ内のファイルを削除または名前変更することを防ぎます。;これはディレクトリの制限された削除フラグと呼ばれ、通常はグローバルに書き込み可能なディレクトリ（たとえば、以前の/tmpシステムの一般的なファイルなど）にあります。このビットはプログラムのテキストイメージをスワップデバイスに保存し、実行時により速くロードします。粘り強いビートと呼んだ。

関連情報