web-dev-qa-db-ja.com

グループのchmod（1）がACLマスクに影響するのはなぜですか？

私はこのUnixの動作を理解しようとしています（私はたまたまUbuntu 11.10でテストしています）。

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Chmod（1）コマンドがACLマスクを更新したことに注意してください。なぜこれが起こるのですか？

SunOSのマンページ には、次のように書かれています。

Chmod（1）コマンドを使用して、ACLエントリを持つファイルのファイルグループ所有者権限を変更すると、ファイルグループ所有者権限とACLマスクの両方が新しい権限に変更されます。新しいACLマスクのアクセス許可は、ファイルにACLエントリを持つ追加のユーザーとグループの有効なアクセス許可を変更する可能性があることに注意してください。

Chmod（1）にこの動作がなかったら便利だと思います。なぜそれが何をするのかを理解することで、ファイルシステムのアクセス許可をどのように設定するかをよりよく設計できることを願っています。

unixfilesystemsaccess-control-list
17
Michael Kropat

chmod()にこのような動作がなかった場合、不便です。

人々が伝統的にUnixで作業することを期待していたものが壊れるので、それは非常に不便でしょう。この振る舞いはあなたによく役立ちますが、あなたはそれを知っていました。

IEEE 1003.1eが標準になったことがなく、1998年に撤回されたのは残念です。実際には、14年後には Linux から FreeBSD）までの幅広いオペレーティングシステムが標準となっています。 to Solaris —実際に実装します。

IEEE 1003.1eワーキングドラフト＃17は興味深い読み物になり、私はそれをお勧めします。付録B§23.3では、ワーキンググループは、古い_S_IRWXG_グループ権限フラグに関してPOSIX ACLが機能するやや複雑な方法について、詳細な8ページの根拠を提供します。 （TRUSIXの人々が10年前にほとんど同じ分析を提供したことは注目に値します。）私はそれをすべてここにコピーするつもりはありません。詳細については、ドラフト標準の理論的根拠をお読みください。これはの簡単な例です：

  • SunOSのマニュアルが間違っています。それは読むべきです

    chmod(1)コマンドを使用して、ACLエントリを持つファイルのファイルグループ所有者権限を変更する場合、どちらかファイルグループ所有者権限またはACLマスクが新しい権限に変更されます。

    これは、現在のマニュアルページに記載されている内容にかかわらず、質問で発生を確認できる動作です。これは、ドラフトPOSIX標準で指定されている動作でもあります。 _CLASS_OBJ_（SunおよびTRUSIXの_ACL_MASK_）アクセス制御エントリの用語が存在する場合は、chmod()のグループビットがそれを設定し、そうでない場合は_GROUP_OBJ_アクセスを設定します。 -制御エントリ。

  • これが当てはまらない場合、 `chmod（）`でさまざまな標準的なことを実行するアプリケーションは、 `chmod（）`が従来の非ACL Unixで伝統的に機能することを期待して、ギャップのあるセキュリティホールを残すか、彼らはセキュリティホールにギャップがあると考えています：

    • 従来のUnixアプリケーションは、chmod(…,000)を使用して、ファイル、名前付きパイプ、デバイス、またはディレクトリへのすべてのアクセスを拒否できることを期待しています。 ACLが存在する場合、これは、古い_S_IRWXG_が_CLASS_OBJ_にマップされている場合にのみ、allユーザーおよびグループのアクセス許可をオフにします。これがないと、古いファイルのアクセス許可を_000_に設定しても、USERまたはGROUPのエントリには影響がなく、他のユーザーは驚くべきことに、引き続きオブジェクトにアクセスできます。

      _chmod 000_を使用してファイルの許可ビットを一時的にアクセス不可に変更してから再度変更するのは古いファイルロックメカニズムで、Unixがアドバイザリロックメカニズムを取得する前に使用されていました —ご覧のとおり—人々は今でも使用しています今日 。

    • 従来のUnixスクリプトは、_chmod go-rwx_を実行でき、オブジェクトの所有者のみがオブジェクトにアクセスできることを期待しています。再び —ご覧のとおり—これはまだ受け取られた知恵です 12年後。そして、これは、古い_S_IRWXG_が存在する場合に_CLASS_OBJ_にマップしない限り機能しません。それ以外の場合、chmodコマンドはUSERまたはGROUPアクセス制御エントリ。所有者以外のユーザーと非所有グループが、アクセス可能であることが期待されているへのアクセスを保持します所有者にのみ。

    • 許可ビットが別の方法で分離されており、ACLでandedされているシステムでは、ほとんどの場合、ファイル許可フラグをrwxrwxrwxにする必要があります。世界が書き込み可能なものだと考えるものを見るとき。

      許可ビットが別の方法で分離されており、ACLでoredされているシステムでは、前述のchmod(…,000)問題が発生します。

参考文献

24
JdeBP

この動作はPOSIX ACLエントリにのみ適用されます。これがここにある理由は、フォルダーがあり、そのフォルダー内にファイルが存在する場合、rwx（例えば）フォルダーとファイルとしてaclすることができるためです。ファイルのグループ権限がrw-である場合（これは典型的なシナリオである可能性があります）、ACLがrwxを明示的に示していても、マスクはaclにrw-の有効な権限を与えます。

一方、ほとんど常に+ xであるディレクトリには、+ xも許可する有効なACLマスク権限があります。

要約すると、このマスクは基本的に、POSIX ACLセットのファイルとフォルダー間の権限を区別するために使用されます。これにより、通常は実行できないはずのファイルが実行可能になりません。

0
Matthew Ife