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では、ルートのみがファイル所有者を変更できるため、ルートの操作はどのような状況でも制限されません。
SysVや他のシステムでは、ファイルの所有者がファイルのユーザーとグループを変更することを許可（または許可するために使用）しますが、これらのシステムでも上記のテキストは私には理解されていません。いいですね。ある人がそれを行うと、その人はもはやファイルの所有者ではないため、chown someone-else the-fileそれ以降は操作を実行できません。ただし、最初の操作（ファイル所有者を保持）をchgrp something-else the-file実行するのを防ぐことはできません。後続の操作は、上記のテキストが言うものとまったく一致しません。chgrpchown
私は何かを理解していません。必要な所有者は現在、グループのメンバーではありません。問題に関連しています。
それでは、これを達成するためにどのような条件が必要でしょうか？所有者とグループの両方が変更されないと、chown（）関数が失敗する可能性があります。、そしてどのようなシステムで？
ベストアンサー1
これMicrosoft Interix Unix サブシステム （現在は引退）これは、NTカーネルが他のカーネルとは若干異なる方法でユーザーとグループの権限を処理するためです。
ユーザーとグループの情報は、次の場所に保存されます。安全なデータベースアクセス。ユーザーとグループは両方とも同じデータベースに保存されますが、グループとユーザー名は一意である必要があります。どのグループもユーザー名を所有できず、その逆も同様です。（このデータベースはUNIXと
/etc/passwdファイルを置き換えます。）/etc/groupsユーザーとグループは、適切なWindowsメソッドを使用して作成されます。(ユーザー管理者、Active Directory ユーザーとコンピューター、またはローカルユーザーとグループ)または、Win32net userコマンドを使用します。（ユーザーを作成および削除するためのサンプルシェルスクリプトはディレクトリに含まれています/usr/examples/admin。）ユーザーは複数のグループに所属できます。
ここにいる一部マニュアルでより具体的に抜粋した内容は次のとおりです。
Windowsでは、ユーザーまたはグループはオブジェクトを所有できます。これは、ユーザーだけがオブジェクトを所有するUNIXとは異なります。
Windowsはセキュリティ識別子を使用して、すべてのユーザーとグループを内部的に識別します。(セキュリティ識別コード)。ハッシュアルゴリズムは一意のSID値を生成します。両方のユーザーまたはグループは同じSIDを持ちません。
オブジェクトへのアクセス権を持つユーザーとグループは、そのSIDによって識別されます。 Windowsが保護できるすべてのオブジェクトには、アクセス制御項目（ACE）と呼ばれる個々の項目で構成されるランダムアクセス制御リスト（DACL）があります。 ACE には、ユーザーまたはグループ SID と、単一のユーザーまたはグループがオブジェクトに対して持つアクセス権の説明という 2 つの重要な情報が含まれます。
...ファイルのグループIDの変更... chgrp（1）を呼び出すユーザーは、指定されたグループに属している必要があり、ファイルの所有者または適切な権限を持っている必要があります。
...所有者とグループのオペランドはどちらもオプションですが、1つだけを指定する必要があります。グループオペランドを指定する場合は、前にコロン（:）を付ける必要があります。
所有者は、数値のユーザー ID またはユーザー名で指定できます。ユーザー名が数値ユーザーIDでもある場合、オペランドはユーザー名として使用されます。グループは、数値のグループIDまたはグループ名にすることができます。グループ名が数値グループIDでもある場合、オペランドはグループ名として使用されます。
セキュリティ上の理由から、ファイルの所有権は適切な権限を持つプロセスによってのみ変更できます。
私が読んだように、これはあなたのユーザーアカウントがWindowsグループに属し、そのグループが所有するファイルの権限を変更するのに十分な権限がある場合、実際にはユーザーアカウントchgrpのファイルアクセス制御の範囲外です。これはchown、明示的なパラメータを使用したuser:group場合よりも制御力が低下するのと同じです。この場合は報告できません。user: そして :groupそうしないと、決して同じ結果が得られません。
これはリンクですInterixがWindows ACLとどのように対話するかを学び、この知識を他のUnixバリアントのSambaファイルシステムに適用する方法に焦点を当てます。
これはリンクですこれまで役に立たないSolaris のマニュアルには、調整可能なパラメータが記載されていますrstchown。
システムコールのPOSIXセマンティクスが
chown(2)有効かどうかを示します。
明らかに、パラメータが値に設定されている場合0...
...POSIXセマンティクスをオフにすると、さまざまなセキュリティの脆弱性が発生する可能性があります。これも可能性があります。ユーザーはファイルの所有権を別のユーザーに変更してファイルを検索できません。返すためにユーザーやシステム管理者の介入は必要ありません。
これらのオプションはSolarisを有効にしません。POSIX適合性。オプションなので十分に作れます。一貫した:
すべてのPOSIX.1-2008準拠の実装は、以下に説明するすべての機能をサポートしますが、削除または変更が可能なシステム関連またはファイルシステム関連の構成手順 これらの機能の一部または全部。厳格なコンプライアンスが必要な場合は、これらの構成を実行しないでください。
次のシンボル定数は、-1以外の値として定義する必要があります。定数がゼロ値として定義されている場合、アプリケーションは関数またはユーティリティを使用して、その
sysconf()時点pathconf()またはfpathconf()問題getconfの特定のパス名に対してシステムにどのような機能があるかを確認する必要があります。_POSIX_CHOWN_RESTRICTED
使用は
chown()適切な権限を持つプロセスに制限され、ファイル内のグループIDはプロセスの有効グループIDまたは補助グループIDのいずれかにのみ変更できます。
システムchown()機能 - 両当事者が録音したシステムコール。chownそしてchgrpシェルユーティリティ - はい指定できませんでした。多くの理由のため。その中には：
EACCESパスプレフィックスのコンポーネントに対する検索権限が拒否されました。
ELOOPパスパラメータの解析中に見つかったシンボリックリンクに循環があります。
EPERM有効なユーザーIDがファイル所有者と一致しないか、呼び出しプロセスに適切な権限がありません。_POSIX_CHOWN_RESTRICTEDそのような特権の必要性を示してください。
ただし、root以外のユーザーに権限の変更権限を付与する行為は、Solarisでのみ発生したことはありません。持つとても素晴らしい- やや古い場合 - Unixファイル権限の適用範囲このフォーラムの投稿著者はその本で次のように言います。
もともとUNIXでは、ファイル所有者がファイルを捨てることを許可しました。ファイル所有者は所有者を他の人に変更できます。 root以外のユーザーはこの操作を元に戻すことはできません... BSD[後]
chownroot以外のユーザーから削除されました...[理由の一部]...これは、ユーザーがファイルシステムに持つことができるディスク容量を制限できるディスククォータを実装します。いたずらユーザーは、クォータをこっそりめくるために大きなファイルを削除できます。
chown今日では、root以外の人がファイルにアクセスできるかどうかを話すのは難しいです。多くのUnixバージョンでは、次のことができます。両方アクション...
もう一つの良いもの - そして最近のもの -メーリングリストの投稿これを引用し続けなさい:
ほとんどのオペレーティングシステムのデフォルト設定は
chownrootユーザーに制限されています。安全上の理由からそのまま維持することに合意した。非ルートユーザーがファイル所有者を変更し、実行ビットがオンになっている場合とビットをクリアする必要SUIDがあります。SGIDこれは起こるかもしれないし起こらないかもしれませんroot。私は最後の段落が良い指摘だと思います。
この記事では、
CAP_CHOWNLinuxで施設を制御する方法も言及されています。POSIX_CHOWN_RESTRICTED（これは動作にのみ影響します）。CAP_FOWNER若干異なる動作をする能力もあります。
そして2003年に指摘されました。:
少なくともHPUXでは、ファイルの所有者を変更できます。（
root例えば）権限を持つユーザーでなくても...
...設定パラメータによって異なりますsetprivgroup。
いずれにせよ、root以外のユーザーがファイル権限を操作できることが可能です。理由あなたの質問を引用すると、ユーザーはそのユーザーがchown所有するファイルを持っているため、他のユーザーがそのファイルを所有する可能性があります。ファイルのグループ所有権がchownユーザーグループと一致しない場合、ユーザーはファイルを変更できなくなります。
この場合chown それから chgrpユーザーがファイルの権限を変更する権限を持っていないため、失敗しますchown user:group。グループそれはユーザー自身の一つです。成功します。
持つおそらく他の多くのニッチの状況でも同様の結果が出ることがあります。これにはディレクトリを含めることができます。難しいそして/または設定ビット、ファイルシステム、および/または実装固有のアクセス制御リスト。このスレッド面白いです。数多くの順列は私自身の微弱な理解をはるかに超えています。これがまさにこの答えがウィキペディアで書かれた理由です。この記事を読んでいる場合は、改善が必要だと信じています。どうぞ。
-Rまた、次のように再帰アプリケーションの失敗を引き起こす可能性があるファイル権限、ツリーナビゲーション、およびシンボリックリンクのさまざまな効果に関する広範な文書もありますchown。
~からPOSIX XRAT章のタイトル第三そして4番目のドメイン:
通常、ファイル階層の巡回オプションを指定するユーザーは単一の物理層で作業したいので、階層外のファイルを参照できるシンボリックリンクは無視されます。たとえば、chownowner ファイルは、-R オプションを指定した同じコマンドとは異なる操作です。この例では、コマンドの動作をここで説明し、
chownownerfileコマンドの動作は次のとおりです。chown -R所有者ファイルは、3番目と4番目のフィールドで説明されています。...基本的な論理歩行にはセキュリティ上の問題があります。歴史的に命令は
chown -Rユーザーファイルはスーパーユーザーにとって安全です。設定値そして設定ファイルの所有権が変更されると、ビットが失われます。パトロールが論理的な場合、ユーザーがツリー内のファイルへのシンボリックリンクを挿入した可能性があるため、所有権を変更することはもはや安全ではありません。繰り返しますが、シンボリックリンクを介して間接的にナビゲートしないように階層ナビゲーションを実行するコマンドにオプションを追加する必要があり、再帰ナビゲーションを実行する履歴スクリプトはすぐにセキュリティの問題になります。これは主にシステム管理者の問題ですが、さまざまなユーザーカテゴリに異なるデフォルト値を設定しないことをお勧めします。...
4.3 BSD では、
chgrpツリー巡回中にシンボリックリンクの対象ではないグループが変更されます。 4.4 BSD のシンボリックリンクには、所有者、グループ、モード、その他の標準 UNIX システムファイル属性はありません。
POSIXではchgrp正しいページには、不完全な可能性のある-R再帰操作、または少なくとも何かを指すものがあります。使用されるになる:
System V と BSD のバージョンは異なる終了ステータスコードを使用します。一部の実装では、終了ステータスを発生したエラーの数として使用します。このアプローチは、有効な終了状態値の範囲をオーバーフローする可能性があるため、機能しません。標準開発者は、終了値として0と> 0のみを指定してそれをマスクすることにしました。