ほとんどのファイル システムには、ファイル システムの内容の読み取り、変更、移動、実行をユーザーが制御するファイルとディレクトリの属性が含まれています。場合によっては、メニュー オプションまたは機能がユーザーの権限レベルに応じて表示または非表示になることがあります。このような種類のユーザー インターフェイスは、権限駆動型と呼ばれます。
広く利用可能な権限には、 POSIXファイル システム権限と、より具体的な制御が可能な アクセス制御リスト(ACL)の 2 種類があります。
ファイルシステムのバリエーション
オリジナルのファイル アロケーション テーブルファイル システムには、ファイルごとに全ユーザー読み取り専用属性があります。
Microsoft Windows NTおよびその派生製品に実装されているNTFSは、ACL [1]を使用して複雑な権限セットを提供します。
OpenVMS はUnix に似た権限スキームを使用します。4 つのカテゴリ (システム、所有者、グループ、およびワールド) と 4 つのアクセス権限タイプ (読み取り、書き込み、実行、および削除) があります。カテゴリは相互に分離されていません。ワールドにはグループが含まれ、グループには所有者が含まれます。システム カテゴリには、システム ユーザーが独立して含まれます。[2]
Classic Mac OSオペレーティングシステムに実装されているHFSおよびその後継のHFS+ は、アクセス許可をサポートしていません。
macOS はPOSIX 準拠の権限を使用し、HFS+ とAPFS の両方でそれをサポートしています。バージョン 10.4 ("Tiger") 以降では、POSIX 準拠の権限に加えて NFSv4 ACL の使用もサポートしています。Apple Mac OS X Server バージョン 10.4+ のファイル サービス管理マニュアルでは、可能であれば従来の Unix 権限のみを使用することを推奨しています。macOS は、Classic Mac OS の "Protected" 属性も引き続きサポートしています。
Solaris ACLのサポートは使用されているファイルシステムに依存します。古いUFSファイルシステムはPOSIX.1e ACLをサポートしていますが、ZFSはNFSv4 ACLのみをサポートしています。[3]
Linuxは、ext2、ext3、ext4、Btrfsなどのファイルシステムをサポートしており、その多くにはPOSIX.1e ACLが含まれています。ext3 [4]およびext4ファイルシステムでは、NFSv4 ACLが実験的にサポートされています。
FreeBSDはUFS上でPOSIX.1e ACLをサポートし、UFSとZFS上でNFSv4 ACLをサポートしています。[5] [6]
IBM z/OSはRACF(リソースアクセス制御機能)を使用してファイルセキュリティを実装しています[7] [永久デッドリンク ]
AmigaOS ファイルシステムである AmigaDOS は、シングルユーザー OS としては比較的高度な権限システムをサポートしています。AmigaOS 1.x では、ファイルにはアーカイブ、読み取り、書き込み、実行、および削除 (まとめて ARWED と呼ばれます) の権限/フラグがありました。AmigaOS 2.x 以降では、さらに Hold、Script、および Pure の権限/フラグが追加されました。
OpenHarmonyオペレーティングシステムは、Oniro OSとHarmonyOSのクライアント側エコシステムと並んで、HarmonyOS NEXTバージョンとLinuxベースの openEulerサーバーOSとともに、アクセストークンマネージャー(ロールベースのアクセス制御)とコアファイルキットAPI機能ベースのきめ細かい権限管理をサポートするHarmony分散ファイルシステム(HMDFS)をネイティブに使用します(openEulerを除く)。[8] [検証失敗]
POSIX パーミッション
Unix系ファイルシステムのパーミッションはPOSIX.1-2017標準[9]で定義されており、所有者、グループ、その他と呼ばれる3つのスコープまたはクラスが使用されます。ファイルが作成されると、そのファイルのパーミッションはそれを作成したプロセスの umaskによって制限されます。
クラス
ファイルとディレクトリはユーザーによって所有されます。所有者によってファイルのユーザー クラスが決まります。所有者には個別の権限が適用されます。
ファイルとディレクトリには、ファイルのグループ クラスを定義するグループが割り当てられます。ファイルのグループのメンバーには、個別の権限が適用されます。所有者は、ファイルのグループのメンバーである場合があります。
所有者でもグループのメンバーでもないユーザーは、ファイルのその他のクラスを構成します。その他のユーザーには、異なる権限が適用されます。
有効な権限は、ユーザー、グループ、その他の順で、ユーザーが属する最初のクラスに基づいて決定されます。たとえば、ファイルの所有者であるユーザーには、グループ クラスまたはその他のクラスに割り当てられている権限に関係なく、ユーザー クラスに与えられた権限が与えられます。
権限
Unix ライクなシステムでは、各クラスに適用される 3 つの特定の権限が実装されています。
- 読み取り権限は、ファイルを読み取る権限を付与します。ディレクトリに設定すると、この権限により、ディレクトリ内のファイルの名前を読み取る権限が付与されますが、内容、ファイルの種類、サイズ、所有権、権限などの詳細情報を取得することはできません。
- 書き込み権限は、ファイルを変更する権限を付与します。ディレクトリに設定すると、この権限により、ファイルの作成、ファイルの削除、ファイル名の変更など、ディレクトリ内のエントリを変更する権限が付与されます。これには、実行権限も設定されている必要があります。実行権限が設定されていない場合、ディレクトリに対する書き込み権限は意味を持ちません。
- 実行権限は、ファイルを実行する権限を付与します。実行可能プログラムに対してこの権限を設定し、オペレーティング システムで実行できるようにする必要があります。ディレクトリに対して設定した場合、実行権限は検索権限として解釈されます。つまり、名前がわかっている場合はファイルの内容とメタ情報にアクセスする権限を付与しますが、読み取り権限も設定されていない限り、ディレクトリ内のファイルを一覧表示することはできません。
ファイルではなくディレクトリに権限を設定することの影響は、「最も頻繁に誤解されるファイル権限の問題の1つ」です。[10]
権限が設定されていない場合、対応する権限は拒否されます。ACL ベースのシステムとは異なり、Unix 系システムでは権限は継承されません。ディレクトリ内に作成されたファイルは、必ずしもそのディレクトリと同じ権限を持つわけではありません。
setuid、setgid、スティッキービットによる権限の動作の変更
Unix ライクなシステムでは、通常、3 つの追加モードが採用されています。これらは実際には属性ですが、権限またはモードと呼ばれます。これらの特別なモードは、クラス別ではなく、ファイルまたはディレクトリ全体に適用されます。ただし、記号表記 (下記参照) では、setuid ビットはユーザーの 3 ビットに設定され、setgid ビットはグループの 3 ビットに設定され、sticky ビットはその他の 3 ビットに設定されます。
- set user ID、setuid、または SUID モード。 setuid が指定されたファイルを実行すると、結果のプロセスは所有者クラスに与えられた有効なユーザー ID を引き継ぎます。これにより、ユーザーを一時的に root (または別のユーザー) として扱うことができます。
- 設定されたグループ ID、setgid、または SGID 権限。setgidが指定されたファイルを実行すると、結果のプロセスはグループ クラスに指定されたグループ IDを想定します。 setgid がディレクトリに適用されると、そのディレクトリの下に作成された新しいファイルとディレクトリは、そのディレクトリからグループを継承します。 (デフォルトの動作では、新しいファイルとディレクトリのグループを設定するときに、有効なユーザーのプライマリ グループを使用します。ただし、BSD 由来のシステムでは、setgid ビットが常にすべてのディレクトリに設定されているかのように動作します ( Setuid を参照)。)
- スティッキーモード (テキストモードとも呼ばれます)。実行可能ファイル上のスティッキー ビットの従来の動作は、カーネルがプロセスイメージを終了後もメモリ内に保持するように促すことでしたが、現在ではこのようなスティッキー ビットの使用は少数の Unix 系オペレーティング システム (HP-UX および UnixWare) のみに制限されています。ディレクトリでは、スティッキー パーミッションにより、ディレクトリへの書き込みパーミッションがある場合でも、ユーザーは自分以外のユーザーが所有するファイルの名前変更、移動、または削除ができなくなります。ディレクトリ所有者とスーパーユーザーだけがこの例外となります。
これらの追加モードは、それぞれ 1 ビットのみを占有するため、 setuid ビット、setgid ビット、およびスティッキー ビットとも呼ばれます。
従来の Unix パーミッションの表記
記号表記
Unix の権限は、記号表記または 8 進表記のいずれかで表されます。
コマンドで使用される最も一般的な形式は、記号表記法ls -lです。
表示される最初の文字はファイルの種類lsを示し、権限とは関係ありません。残りの 9 文字は 3 つのセットに分かれており、それぞれ 3 文字で権限のクラスを表します。最初のセットはユーザークラスを表します。2 番目のセットはグループクラスを表します。3 番目のセットはその他のクラスを表します。
3 つの文字はそれぞれ、読み取り、書き込み、実行の権限を表します。
r読み取りが許可されている場合、-許可されていない場合。w書き込みが許可されている場合、-許可されていない場合。x実行が許可される場合は許可され、-そうでない場合は実行が許可されます。
以下に記号表記の例をいくつか示します。
-rwxr-xr-x: ユーザー クラスには完全な権限があり、グループとその他のクラスには読み取りと実行の権限のみがある通常のファイル。crw-rw-r--: ユーザーおよびグループ クラスに読み取りおよび書き込み権限があり、その他のクラスには読み取り権限のみがある文字特殊ファイル。dr-x------: ユーザー クラスに読み取りおよび実行権限があり、グループおよびその他のクラスに権限がないディレクトリ。
一部の権限システムでは、ls -l画面に表示される追加のシンボルが追加の権限機能を表します。
- + (プラス) サフィックスは、追加の権限を制御できるアクセス制御リストを示します。
- . (ドット) サフィックスは、SELinuxコンテキストが存在することを示します。詳細は、コマンド . で一覧表示できます
ls -Z。 - @ サフィックスは拡張ファイル属性が存在することを示します。
setuid、setgid、およびsticky または text属性を表すには 、実行可能文字 (xまたは-) を変更します。これらの属性は、1 つのクラスのユーザーだけでなく、ファイル全体に影響しますが、setuid 属性はユーザーの 3 要素内の実行可能文字を変更し、setgid 属性はグループの 3 要素内の実行可能文字を変更し、sticky または text 属性はその他の 3 要素内の実行可能文字を変更します。setuid または setgid 属性の場合、最初または 2 番目の 3 要素ではxが になりs、 は に-なりますS。sticky または text 属性の場合、3 番目の 3 要素ではxが になりt、 は に-なりますT。次に例を示します。
-rwsr-Sr-t: ユーザー クラスに読み取り、書き込み、実行権限があり、グループ クラスに読み取り権限があり、その他クラスに読み取りと実行権限があり、 setuid、setgid、sticky属性が設定されているファイル。
数値表記
Unix の権限を表す別の方法は、で示すように8 進数 (基数 8) 表記ですstat -c %a。この表記は少なくとも 3 桁で構成されます。右端の 3 桁はそれぞれ、権限の異なるコンポーネント (所有者、グループ、その他) を表します。(4 番目の桁がある場合、左端 (上位) の桁は、setuid ビット、setgid ビット、およびスティッキー ビットという 3 つの追加属性を表します。)
これらの各数字は、 2 進数表記におけるその構成ビットの合計です。その結果、特定のビットが合計に加算され、数字で表されます。
- 読み取ったビットは合計に4を加算します(2進数では100)。
- 書き込みビットは合計に2を加算します(2進数では010)。
- 実行ビットは合計に 1 を追加します (バイナリでは 001)。
これらの値の組み合わせがあいまいになることは決してありません。それぞれの合計は特定の権限セットを表します。より技術的に言えば、これはビット フィールドの 8 進表現です。各ビットは個別の権限を参照し、8 進数で一度に 3 ビットをグループ化することは、これらの権限をユーザー、グループ、その他別にグループ化することに対応します。
これらは、8 進表記法で示された記号表記セクションの例です。
ユーザープライベートグループ
一部のシステムでは、ユーザーとグループの従来の POSIX モデルから逸脱し、各ユーザーに新しいグループ (「ユーザー プライベート グループ」) を作成します。各ユーザーがそのユーザー プライベート グループの唯一のメンバーであると仮定すると、このスキームでは、通常のディレクトリに新しく作成されたファイルに他のユーザーが書き込むことを許可せずに umask 002 を使用できます。これは、そのようなファイルは作成者のプライベート グループに割り当てられるためです。ただし、ファイルを共有することが望ましい場合、管理者は必要なユーザーを含むグループを作成し、新しいグループに割り当てられたグループ書き込み可能なディレクトリを作成し、最も重要なこととして、ディレクトリを setgid にすることができます。setgid にすると、そのディレクトリで作成されたファイルはディレクトリと同じグループに割り当てられ、002 umask (ユーザー プライベート グループを使用することで有効になります) により、グループの他のメンバーがそれらのファイルに書き込むことができるようになります。[11] [12]
参照
- chattrまたは chflags: アクセスを制限するものも含め、属性またはフラグを変更します。
- chmod : Unix 系ファイルシステムのモード (権限) を変更する
- lsattr属性をリストする
- ファイルシステムの比較 § メタデータ
- グループ識別子(Unix)
- POSIX
- umask
- ユーザー識別子(Unix)
参考文献
- ^ 「ファイルとフォルダーのアクセス許可」。Microsoft。2009 年 12 月 9 日。
- ^ 「OpenVMS ドキュメント」。2012 年 3 月 5 日時点のオリジナルよりアーカイブ。2009 年 6 月 6 日閲覧。
- ^ 「Oracle Solaris ZFS 管理ガイド」(PDF) 2010 年 9 月。
- ^ 「Linux 上のネイティブ NFSv4 ACL」。2008 年 10 月 12 日時点のオリジナルよりアーカイブ。2010 年 5 月 4 日に取得。
- ^ 「NFSv4_ACLs – FreeBSD Wiki」。
- ^ 「FreeNAS 9.1.1 ユーザーガイド」(PDF)。 2013年。
- ^ 「IBM ナレッジ センター」。
- ^ 「HarmonyOS 分散ファイルシステム開発ガイド」。Substack。LivingInHarmonyブログ。2024 年 3 月 13 日。2024 年3 月 13 日に閲覧。
- ^ 「定義、3.175 ファイル権限ビット」。pubs.opengroup.org。2018-07-22 。2023-06-24に閲覧。
- ^ Hatch, Bri. 「Linux ファイル パーミッションの混乱 パート 2」、『Hacking Linux Exposed』、2003 年 4 月 24 日、2011 年 7 月 6 日アクセス。
- ^ Epstein, Brian. 「Unix におけるユーザー プライベート グループの仕組みと理由」。security.ias.edu。Institute for Advanced Study Network Security。2014 年 8 月 8 日時点のオリジナルよりアーカイブ。2014年8 月 5 日閲覧。
- ^ 「Red Hat Enterprise Linux 7 システム管理者ガイド、4.3.4 グループディレクトリの作成」。Red Hat カスタマーポータル。Red Hat。
外部リンク
- Linux クックブック: グループとその使い方 Michael Stutz 著 2004
