chown（1）POSIX仕様の説明

chownユーティリティのPOSIX仕様では、その理論的根拠のセクションでchown user:group構文（以前はchown user.group）（強調マイン）について言及しています。

所有者とグループの両方を指定する4.3 BSDメソッドは、POSIX.1-2008のこのボリュームに含まれています。

• chgrpおよびchown（ユーザーIDのみを変更した）ユーティリティを使用して目的の終了条件を達成できない場合があります。（現在の所有者が目的のグループのメンバーではなく、目的の所有者が現在のグループのメンバーでない場合、chown（）関数は、所有者とグループの両方が同時に変更されない限り失敗する可能性があります。）

user:group構文は便利だと思いました。さて、上記のことは、chown user:groupできないこととできないことがあることを暗示していますchgrp group; chown user

今、そのテキストは私には意味がありません。4.3BSDでは、rootのみが所有者をファイルに変更できるため、どのような場合でも彼ができることには制限がありません。

SysVと他のいくつかのシステムでは、ファイルの所有者がファイルのユーザーとグループを任意に変更できます（または許可するために使用されます）が、これらのシステムでも、上記のテキストは意味がありません。OK、ファイルの所有者ではなくなったため、後でchown someone-else the-file行うことはできませんがchgrp something-else the-file、chgrp最初（ファイルの所有者にとどまる）chown以降を行うことを妨げるものは何もありません。上記のテキストは正確に言っています。

私は、現在のグループのメンバーではなく、希望する所有者が問題にどのように関係しているかを理解していません。

では、所有者とグループの両方が同時に変更されない限り、chown（）関数が失敗する可能性がある条件は何ですか？

NTカーネル用のMicrosoft Interix Unixサブシステム （現在は廃止）は、他のユーザーとは異なる方法でユーザーおよびグループのアクセス許可を扱います。

ユーザーとグループの情報は、セキュリティアクセスデータベースに保存されます。ユーザーとグループは両方とも同じデータベースに格納されますが、グループ名とユーザー名は一意である必要があります。どのグループもユーザー名を持つことはできず、その逆も同様です。（このデータベースは、UNIX の/etc/passwdand /etc/groupsファイルを置き換えます。）ユーザーとグループは、適切なWindows方法論（ユーザーマネージャー、Active Directoryユーザーとコンピューター、またはローカルユーザーとグループ）またはWin32 net userコマンドを使用して作成されます。（ユーザーを作成および削除するシェルスクリプトの例は、ディレクトリに含まれてい/usr/examples/adminます。）ユーザーは多くのグループに所属できます。

以下に、より具体的なマニュアルの抜粋を示します。

Windowsでは、ユーザーまたはグループがオブジェクトを所有できます。これは、ユーザーのみがオブジェクトを所有するUNIXとは異なります。

Windowsは、セキュリティ識別子（SID）を使用して、すべてのユーザーとグループを内部的に識別します。ハッシュアルゴリズムは、一意のSID値を生成します。2人のユーザーまたはグループが同じSIDを持つことはありません。

オブジェクトにアクセスする権限を持つユーザーとグループは、SIDによって識別されます。Windowsで保護できるすべてのオブジェクトには、アクセス制御エントリ（ACE）と呼ばれる個別のエントリで構成される随意アクセス制御リスト（DACL）があります。ACEには、ユーザーまたはグループのSIDと、オブジェクトに対する個々のユーザーまたはグループのアクセス権の説明という2つの重要な情報が含まれています。

CHGRP

...ファイルのグループIDを変更する... chgrp（1）を呼び出すユーザーは、指定されたグループに属し、ファイルの所有者であるか、適切な特権を持っている必要があります。

チャウン

...所有者とグループのオペランドは両方ともオプションです。ただし、1つを指定する必要があります。グループオペランドを指定する場合は、コロン（:)を前に付ける必要があります。

所有者は、数値のユーザーIDまたはユーザー名で指定できます。ユーザー名が数値ユーザーIDでもある場合、オペランドはユーザー名として使用されます。グループは、数値のグループIDまたはグループ名のいずれかです。グループ名が数値グループIDでもある場合、オペランドはグループ名として使用されます。

セキュリティ上の理由から、ファイルの所有権は、適切な特権を持つプロセスによってのみ変更できます。

私が読んだように、ユーザーアカウントが、そのグループが所有するファイルのアクセス許可を変更するための十分な特権を持つWindowsグループに属している場合chgrp、ユーザーアカウントの制御外でそのファイルを効果的に作成することができます。これはchown、明示的なuser:groupパラメーターを使用する場合よりも制御が少なくなります。宣言の可能性なしに、そのコンテキストではuser: と :groupあなたはそうと同じ結果を得ることができなかったん。

InterixがWindows ACLと相互作用する方法の詳細な外観へのリンクは、このような知識が他のUnixバリアントのSambaファイルシステムにどのように適用されるかに焦点を当てています。

以下は、現在使用されていない Solarisドキュメントへのリンクrstchownです。

chown(2)システムコールのPOSIXセマンティクスが有効かどうかを示します...

どうやら、パラメータが値に設定されている場合0...

... POSIXセマンティクスをオフにすると、さまざまなセキュリティホールの可能性が広がります。また、ユーザーがファイルの所有権を別のユーザーに変更し、ユーザーまたはシステム管理者の介入なしにファイルを取り戻すことができない可能性を開きます。

このようなオプションは、SolarisのPOSIX準拠を無効にしません。ただそれがオプションであるというだけで、適合とみなされます：

POSIX.1-2008に準拠するすべての実装は、以下で説明するすべての機能をサポートしますが、 これらの機能の一部またはすべてを削除または変更できるシステム依存またはファイルシステム依存の構成手順が存在する場合があります。厳格なコンプライアンスが必要な場合、このような構成は行わないでください。

次の記号定数は、-1以外の値で定義されます。定数が値ゼロで定義されている場合、アプリケーションが使用する必要がありsysconf()、pathconf()またはfpathconf()機能、または getconfその時点で、または問題の特定のパス名システム上に存在する特徴を決定するために、ユーティリティを。

_POSIX_CHOWN_RESTRICTED

の使用はchown()、適切な特権を持つプロセス、およびプロセスの有効なグループIDまたはその補足グループIDの1つのみにファイルのグループIDを変更することに制限されています。

chown()システム機能-両方製文書化されたシステムコールであるchownとchgrpシェルユーティリティは、 -ている失敗する指定された多くの理由のために。その中で：

EACCES パスプレフィックスのコンポーネントに対する検索許可が拒否されました。

ELOOP パス引数の解決中に発生したシンボリックリンクにループが存在します。

EPERM 実効ユーザーIDがファイルの所有者と一致しないか、呼び出しプロセスに適切な特権がなく、_POSIX_CHOWN_RESTRICTEDはそのような特権が必要であることを示します。

ただし、root以外のユーザーにアクセス許可の変更権を付与する動作は、Solaris固有のものではありませんでした。著者が次のように述べているこのフォーラム投稿では、Unixファイルのアクセス許可が非常に優れています -多少古い場合-

もともと、Unixはファイルの所有者がファイルを渡すことを許可していました。ファイルの所有者は、所有者を他の誰かに変更できます。非rootユーザーがこの操作を取り消す方法はありませんでした... BSD [後で]chown非rootユーザーから削除されました... [一部の理由] ...ディスククォータを実装して、ディスク容量を制限できました。ユーザーはファイルシステム内にいる可能性があります...いたずらなユーザーは、クォータを超えてスニークするために大きなファイルを配布できます。

今日、非ルートがchownファイルを作成できるかどうかを言うのは簡単ではありません。Unixの多くのバージョンでは、両方の動作が許可されています...

別の優れた-そして最近の- メーリングリストの投稿はこれを引用して続けています：

ほとんどのOSのデフォルトでは、chownルートのみに制限されています。また、セキュリティを考慮してこの方法を維持する必要があるというコンセンサスがあります。非rootユーザーがファイルの所有者を変更し、実行ビットがオンになっている場合SUID、SGIDビットとビットをクリアする必要があります。これはで発生する場合と発生しない場合がありrootます。

私は最後の段落がそれをうまく言っていると思います。

また、その記事CAP_CHOWNはLinuxでその機能を制御することにも言及しています（POSIX_CHOWN_RESTRICTED動作にのみ影響するはずです）。CAP_FOWNER機能もあり、動作が少し異なります。

そして、あなたが2003年に指摘したように：

少なくともHPUXでは、特権ユーザーでなくてもファイルの所有者を（rootたとえば）変更できます。

...構成setprivgroupパラメータに依存します。

ルート以外のユーザーがファイル許可を操作できる場合は、質問で引用された根拠に記載されているように、ユーザーはchown別のユーザーが所有するようにそのユーザーが所有するファイルである可能性があります。ファイルのグループ所有権とchowningユーザーのグループが一致しない場合、ユーザーはそのファイルを変更できなくなります。

このシナリオでchown は chgrp、ユーザーにはそのファイルのアクセス許可を変更するアクセス許可がないため、失敗しますがchown user:group、グループがユーザーのものである限り成功します。

同様に生じる可能性のある他の多くのニッチな状況がおそらくあります。これには、ディレクトリスティッキーおよび/またはsetgidビット、ファイルシステムおよび/または実装固有のアクセス制御リストが含まれます。たとえば、このスレッドは興味深いものです。数え切れないほどの順列は、私自身の微弱な把握をはるかに超えています。そのため、この答えはウィキ化されています。あなたがこれを読んでいるなら、あなたはそれを改善する価値があると信じています、そしてあなたはあなたが方法を知っていると信じています-してください。

同様の失敗をもたらす可能性があるファイルのパーミッション、ツリートラバーサル、およびシンボリックリンクの様々な可能性のある影響についての詳細なドキュメントもあります-Recursive chownここでのアプリケーションは：

POSIX XRATのセクションの見出し第三と第四ドメイン：

一般に、ファイル階層トラバーサルのオプションを指定するユーザーは、単一の物理階層での操作を希望するため、階層外のファイルを参照するシンボリックリンクは無視されます。たとえば、chown owner fileは、-Rオプションが指定された同じコマンドとは異なる操作です。この例では、コマンドの動作をchown owner fileここでchown -R説明しますが、コマンド所有者ファイルの動作は3番目と4番目のドメインで説明します。

...デフォルトの論理ウォークにセキュリティ上の問題があります。歴史的に、コマンドのchown -Rため、ユーザーのファイルには、スーパーユーザーのための安全となっているのsetuidとsetgidのファイルの所有権が変更されたときにビットが失われました。ウォークが論理的である場合、ユーザーがツリー内の任意のファイルを指すシンボリックリンクを挿入した可能性があるため、所有権の変更は安全ではなくなります。繰り返しますが、これはシンボリックリンクを介して間接的でない階層トラバーサルを行うコマンドにオプションを追加する必要があり、再帰ウォークを行う歴史的なスクリプトはすぐにセキュリティの問題になります。これは主にシステム管理者にとっての問題ですが、ユーザーのクラスごとに異なるデフォルトを持たないことが望ましいです。

...

4.3 BSDではchgrp、ツリートラバース中に、ターゲットではなくシンボリックリンクのグループが変更されました。4.4 BSDのシンボリックリンクには、所有者、グループ、モード、またはその他の標準UNIXシステムファイル属性がありませんでした。

そして、chgrp適切なPOSIX ページから、可能性のある不完全な-R再帰的アクション、または少なくとも以前は何であったかを指し示しています。

System VおよびBSDバージョンは、異なる終了ステータスコードを使用します。一部の実装では、発生したエラーの数のカウントとして終了ステータスを使用しました。有効な終了ステータス値の範囲をオーバーフローする可能性があるため、この方法は実行できません。標準の開発者は、終了値として0と> 0のみを指定して、これらをマスクすることを選択しました。

前提条件1：chown成功したかどうかを判断するためのルールは、ターゲットユーザーとグループパーツを個別にチェックしますuser_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters)。

仮定2：chown(file, -1, -1)成功。

仮定3：chown成功したかどうかを判断するためのルールは、ファイルが現在属しているグループに依存しません。

当然：chown(file, uid, gid)成功した場合は成功しchown(file, -1, gid) && chown(file, uid, -1)ます。

これらの仮定のいずれかに違反するUnixのバリアントは知りませんが、かなり安全に思えます。

この文は、委員会の誰かが、ps電話の頭にいくつの選択肢が収まるかを議論した後、疲れたときに言ったこと、または秘書が誤って転記したこと、およびレビュー中に誰も捕まえなかったことを示しています。結局、ユーザーとグループを自動的に変更できる他の適切な理由があります。これには、POSIXの根拠にも引用されているパフォーマンスの理由や、原子性（ああ、所有権とアクセス権を変更する呼び出しが1回）。

前提条件3が間違っている可能性があるのは、プロセスがファイル所有者を変更する機能を取得できるシステムですが、ファイル所有者がファイルに対する書き込み権限を持っている場合のみです。多少現実的ですが、これが当てはまるシステムは知りません。次にchgrp、rootとしてもファイルを所有するユーザーとしても実行されていないプロセスからのグループに、後でファイルを制限することができますchown。

再帰呼び出しの場合、単一のパスが成功すると、chgrpパス全体に続いてパス全体chownが失敗するエッジケースがあります。これは、所有者が通過する権限を持っていないディレクトリに関係するため、あまり説得力のある議論ではありません。そのようなすべてのケースから保護したいアプリケーションは、とにかく権限をいじる必要があります。それにもかかわらず、技術的にはこの根拠の条件を満たします。実行中のプロセスにはalice、有効なユーザー、有効なグループstaff、およびファイル所有者を任意に変更する機能があると仮定します（それらを提供するだけでなく、いくつかのUNIXバリアントにはこのような機能がありますが、非ルートプロセスにはめったに付与されません）。

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied