chown(1) POSIX仕様の説明

Question 1

のMicrosoft Interix Unix サブシステム （現在は引退）NT カーネルは、ユーザーとグループの権限を他のものとは少し異なる方法で処理します。

ユーザーとグループの情報は、セキュリティアクセスデータベースユーザーとグループは両方とも同じデータベースに保存されますが、グループ名とユーザー名は一意である必要があります。グループにユーザー名を割り当てることはできません。逆も同様です。(このデータベースはUNIX の/etc/passwdおよび/etc/groupsファイルに代わるものです。)ユーザーとグループは適切なWindowsの方法論を使用して作成される(ユーザーマネージャー、Active Directory ユーザーとコンピューター、またはローカルユーザーとグループ)または Win32net userコマンドを使用します。(ユーザーを作成および削除するためのシェルスクリプトの例は、ディレクトリに含まれています/usr/examples/admin。)ユーザーは複数のグループに所属できます。

ここにはいくつかのより具体的なマニュアルの抜粋:

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

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

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

グラップ

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

チョーン

...所有者オペランドとグループオペランドはどちらもオプションですが、いずれか 1 つを指定する必要があります。グループオペランドを指定する場合は、その前にコロン (:) を付ける必要があります。

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

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

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

リンクはこちらInterix が Windows ACL とどのように相互作用するかを詳細に検討し、その知識が他の Unix バリアントの Samba ファイルシステムにどのように適用されるかに焦点を当てます。

リンクはこちら今に廃止調整可能なパラメータについて説明した Solaris ドキュメントrstchown...

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

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

...POSIXセマンティクスを無効にすると、さまざまなセキュリティホールが発生する可能性があります。また、ユーザーがファイルの所有権を別のユーザーに変更し、ファイルを取得できなくなるユーザーまたはシステム管理者の介入なしに復元できます。

このようなオプションはSolarisのPOSIX準拠それが選択肢であるというだけで、適合する:

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

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

_POSIX_CHOWN_RESTRICTED

の使用は、chown()適切な権限を持つプロセスに制限され、ファイルのグループ ID をプロセスの有効なグループ ID またはその補助グループ ID のいずれかに変更するだけです。

システムchown()関数 - これは、chownそしてchgrpシェルユーティリティ - is失敗すると指定される理由は様々ですが、例えば：

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

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

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

しかし、非ルートユーザーに権限変更権限を与えるという動作は、Solarisに特有のものではありません。非常に素晴らしい- 多少古いですが - Unixのファイル権限についてこのフォーラム投稿著者は次のように述べています。

もともと、Unix ではファイル所有者がファイルを譲渡することができました。ファイルの所有者は、所有者を他のユーザーに変更することができました。非ルートユーザーがこの操作を元に戻す方法はありませんでした... BSD[後で]chown非ルートユーザーから削除...[一部は]...ディスククォータを実装し、ユーザーがファイルシステム内で使用できるディスク領域を制限できるようになりました... 悪質なユーザーは、クォータをすり抜けるために大きなファイルを配布する可能性があります。

現在、非ルートユーザーがchownファイルを操作できるかどうかを判断するのは簡単ではありません。多くのバージョンのUnixでは、両方行動...

もう一つの良い点は、最近のメーリングリスト投稿これを引用し、次のように続けている。

ほとんどの OS のデフォルトでは、はchownroot のみに制限されています。セキュリティ上の理由から、この設定のままにしておくべきであるという意見が一致しています。非 root ユーザーがファイルの所有者を変更し、実行ビットがオンになっている場合は、とSUIDビットSGIDをクリアする必要があります。では、この動作が行われる場合と行われない場合がありますroot。

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

その記事ではCAP_CHOWNLinux上でその機能を制御する方法についても言及している。（動作にのみ影響するはずですPOSIX_CHOWN_RESTRICTED）CAP_FOWNER動作が少し異なる機能もあります。

そして2003年にあなたが指摘した:

少なくともHPUXでは、ファイルの所有者を変更できることに注意してください。（root例えば）たとえ特権ユーザーでなくても...

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

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

このシナリオではchown それから chgrpユーザーはそのファイルの権限を変更する権限を持たなくなるため、失敗します。一方chown user:group、グループユーザー自身の中に - 成功するでしょう。

があるおそらく同様の結果になる可能性のある他の多くのニッチな状況には、ディレクトリが含まれる可能性があります粘着性および/または設定されたビット、ファイルシステム、および/または実装固有のアクセス制御リスト。このスレッド例えば、興味深いです。無数の組み合わせは私の貧弱な理解をはるかに超えています。そのため、この回答はウィキペディアに掲載されています。これを読んでいるということは、改善する価値があると信じており、その方法を知っていると信じているということです。してください。

-Rまた、ファイル権限、ツリートラバーサル、およびシンボリックリンクが、再帰chownアプリケーションに関して同様の障害を引き起こす可能性のあるさまざまな影響について、詳細なドキュメントがここにあります。

からPOSIX の XRATセクション見出し三番目そして第四の領域:

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

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

...

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

そしてPOSIXからchgrpページの右側には、不完全な-R回帰アクションの可能性、または少なくとも使用済みすることが：

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

Answer

のMicrosoft Interix Unix サブシステム （現在は引退）NT カーネルは、ユーザーとグループの権限を他のものとは少し異なる方法で処理します。

ユーザーとグループの情報は、セキュリティアクセスデータベースユーザーとグループは両方とも同じデータベースに保存されますが、グループ名とユーザー名は一意である必要があります。グループにユーザー名を割り当てることはできません。逆も同様です。(このデータベースはUNIX の/etc/passwdおよび/etc/groupsファイルに代わるものです。)ユーザーとグループは適切なWindowsの方法論を使用して作成される(ユーザーマネージャー、Active Directory ユーザーとコンピューター、またはローカルユーザーとグループ)または Win32net userコマンドを使用します。(ユーザーを作成および削除するためのシェルスクリプトの例は、ディレクトリに含まれています/usr/examples/admin。)ユーザーは複数のグループに所属できます。

ここにはいくつかのより具体的なマニュアルの抜粋:

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

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

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

グラップ

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

チョーン

...所有者オペランドとグループオペランドはどちらもオプションですが、いずれか 1 つを指定する必要があります。グループオペランドを指定する場合は、その前にコロン (:) を付ける必要があります。

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

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

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

リンクはこちらInterix が Windows ACL とどのように相互作用するかを詳細に検討し、その知識が他の Unix バリアントの Samba ファイルシステムにどのように適用されるかに焦点を当てます。

リンクはこちら今に廃止調整可能なパラメータについて説明した Solaris ドキュメントrstchown...

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

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

...POSIXセマンティクスを無効にすると、さまざまなセキュリティホールが発生する可能性があります。また、ユーザーがファイルの所有権を別のユーザーに変更し、ファイルを取得できなくなるユーザーまたはシステム管理者の介入なしに復元できます。

このようなオプションはSolarisのPOSIX準拠それが選択肢であるというだけで、適合する:

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

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

_POSIX_CHOWN_RESTRICTED

の使用は、chown()適切な権限を持つプロセスに制限され、ファイルのグループ ID をプロセスの有効なグループ ID またはその補助グループ ID のいずれかに変更するだけです。

システムchown()関数 - これは、chownそしてchgrpシェルユーティリティ - is失敗すると指定される理由は様々ですが、例えば：

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

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

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

しかし、非ルートユーザーに権限変更権限を与えるという動作は、Solarisに特有のものではありません。非常に素晴らしい- 多少古いですが - Unixのファイル権限についてこのフォーラム投稿著者は次のように述べています。

もともと、Unix ではファイル所有者がファイルを譲渡することができました。ファイルの所有者は、所有者を他のユーザーに変更することができました。非ルートユーザーがこの操作を元に戻す方法はありませんでした... BSD[後で]chown非ルートユーザーから削除...[一部は]...ディスククォータを実装し、ユーザーがファイルシステム内で使用できるディスク領域を制限できるようになりました... 悪質なユーザーは、クォータをすり抜けるために大きなファイルを配布する可能性があります。

現在、非ルートユーザーがchownファイルを操作できるかどうかを判断するのは簡単ではありません。多くのバージョンのUnixでは、両方行動...

もう一つの良い点は、最近のメーリングリスト投稿これを引用し、次のように続けている。

ほとんどの OS のデフォルトでは、はchownroot のみに制限されています。セキュリティ上の理由から、この設定のままにしておくべきであるという意見が一致しています。非 root ユーザーがファイルの所有者を変更し、実行ビットがオンになっている場合は、とSUIDビットSGIDをクリアする必要があります。では、この動作が行われる場合と行われない場合がありますroot。

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

その記事ではCAP_CHOWNLinux上でその機能を制御する方法についても言及している。（動作にのみ影響するはずですPOSIX_CHOWN_RESTRICTED）CAP_FOWNER動作が少し異なる機能もあります。

そして2003年にあなたが指摘した:

少なくともHPUXでは、ファイルの所有者を変更できることに注意してください。（root例えば）たとえ特権ユーザーでなくても...

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

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

このシナリオではchown それから chgrpユーザーはそのファイルの権限を変更する権限を持たなくなるため、失敗します。一方chown user:group、グループユーザー自身の中に - 成功するでしょう。

があるおそらく同様の結果になる可能性のある他の多くのニッチな状況には、ディレクトリが含まれる可能性があります粘着性および/または設定されたビット、ファイルシステム、および/または実装固有のアクセス制御リスト。このスレッド例えば、興味深いです。無数の組み合わせは私の貧弱な理解をはるかに超えています。そのため、この回答はウィキペディアに掲載されています。これを読んでいるということは、改善する価値があると信じており、その方法を知っていると信じているということです。してください。

-Rまた、ファイル権限、ツリートラバーサル、およびシンボリックリンクが、再帰chownアプリケーションに関して同様の障害を引き起こす可能性のあるさまざまな影響について、詳細なドキュメントがここにあります。

からPOSIX の XRATセクション見出し三番目そして第四の領域:

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

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

...

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

そしてPOSIXからchgrpページの右側には、不完全な-R回帰アクションの可能性、または少なくとも使用済みすることが：

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

Question 2

仮定 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ルートとしてもファイルを所有するユーザーとしても実行されていないプロセスからグループに、後でファイルを使用不可にすることができます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

Answer

仮定 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ルートとしてもファイルを所有するユーザーとしても実行されていないプロセスからグループに、後でファイルを使用不可にすることができます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

chown(1) POSIX仕様の説明

答え1

答え2

関連情報