Linux(Arch Linux)のファイル権限に関して予期しない問題が発生しました。基本的に私は以下を持っています:
userX
存在するgroupX
fileX userX:groupX ---rwx----
私を混乱させるのはこれです:私は(rwx
)で何もできないということですfileX
。これは正しいですか?これが実際に予想される動作であることを確認できる人はいますか?
私ができる唯一のことは、親ディレクトリへの書き込み権限があるmv
からです。rm
問題は、これらの権限が最も一般的な権限(その他 - >グループ - >ユーザー)から始まり、互いに重複していると常に考えてきたことです。つまり、o=rwx
グループとユーザーの権限が何であるか、誰が気になりますか?明らかにそうではありませんが、私にとってはあまり理解できないようです。このアプローチが役に立つ唯一の場所は、非常に具体的な人/グループを簡単に除外することです。これは賢明なアプローチ(IMHO)のようには見えません。さらに、所有者(そしてグループ?)もそうすることができなければなりませんかchmod
?これについて考えていますか?
答え1
問題は、これらの権限が最も一般的な権限(その他 - >グループ - >ユーザー)から始まり、互いに重複していると常に考えてきたことです。
その場合、「その他」権限がすべての人に適用されます。
つまり、o = rwxの場合、グループとユーザーの権限が何であるか、誰が気になりますか?
最後の文とは異なります。ここでは、権限がまたは一緒にあることを意味します。たとえば、userXがファイルを所有し、ユーザーがファイルを読み取ることができる場合、またはuserXが属するグループがファイルを所有し、ファイルをグループとして読み取ることができる場合、userXは読み取り権限を持ちます。 、またはファイルを読み取ることができる場合。しかしそれは真実ではない。実際、これは権限が他の人に適用されますが、他のオブジェクトについては何も言わないことを意味しますo=rwx
。rwx
まず、ユーザーがどのグループに属しているかは直接重要ではありません。カーネルには、グループに属するユーザーの概念はありません。カーネルは各プロセスのユーザーID(有効なUID)とリストグループID(有効GIDと補足GID)。これらのグループは、ログイン時にログインプロセスによって決定されます。ログインプロセスはグループデータベース(たとえば/etc/group
)を読み取ります。ユーザーとグループ ID は子プロセスに継承されます。
プロセスが既存のUnix権限を使用してファイルを開こうとした場合:
- ファイル所有者ユーザーがプロセスの有効なUIDの場合、ユーザー権限ビットが使用されます。
- それ以外の場合、ファイルを所有するグループがプロセスの有効な GID であるか、プロセスの補助グループ ID のいずれかである場合、グループ権限ビットが使用されます。
- それ以外の場合は、別の許可ビットを使用してください。
1セットのrwxビットのみが使用されます。ユーザーはグループよりも優先され、グループは他のグループよりも優先されます。ある時アクセス制御リスト、上記のアルゴリズムは一般化されています。
- プロセスの有効な UID の ACL がファイルに存在する場合は、アクセスを許可するかどうかを決定するために使用されます。
- そうでなく、プロセスの実効 GID またはプロセスの補助グループ ID のいずれかの ACL がファイルに存在する場合、グループ許可ビットが使用されます。
- それ以外の場合は、別の許可ビットを使用してください。
また、見ることができますユーザーが複数のグループに属する場合のACLS優先順位マスキング効果を含むACLエントリの使用方法の詳細。
したがって、-rw----r-- alice interns
Aliceが読み書き可能で、インターンを除く他のすべてのユーザーが読み取ることができるファイルを表します。権限と所有権を持つファイルには、----rwx--- alice interns
Alice以外のインターンのみがアクセスできます(インターンであるかどうかにかかわらず)。 Aliceは権限を変更するために呼び出すことができるため、chmod
これはセキュリティを提供しません。 ACLがあるシステムでは、共通のメカニズムを使用して特定のユーザーまたは特定のグループから権限を削除できます。これは時々便利です。
各タスク(読み取り、書き込み、実行)ごとにビットセットをすべてORするのではなく、ビットセットを使用すると、次の利点があります。
- ACL があるシステムのユーザーまたはグループのセットから権限を削除できるようにするのに便利な効果があります。 ACLがないシステムでは、グループから権限を削除できます。
- 実装する方が簡単です。ビットセットを組み合わせるのではなく、ビットセットを確認してください。
- 関連する作業が少ないため、ファイル権限を分析する方が簡単です。
1次のような場合は変更されることがあります。設定値またはsetgidプロセスが実行されます。これは当面の問題とは関係ありません。
答え2
より具体的な権限は、より具体的な権限よりも優先されます。
グループのユーザーX
ファイルXユーザーX:グループX ---rwx----
あなたはファイルの所有者なので、所有者権限のみが付与されます。所有者に権限がありません。したがって、あなたができることは何もありません。ファイルの所有者ではなくグループメンバーでない場合は、グループ権限が適用されます。
Wikiページのこの部分を読んでください。
https://en.wikipedia.org/wiki/File_system_permissions#Classes
答え3
-rwxrw----
これは、所有者が読み取り、書き込み、および実行権限を持ち、彼が属するグループが読み取りおよび書き込み権限を持ち、他のグループに権限がないことを意味します。
指定した権限は、ファイルを読み取り、書き込み、および実行できる「groupX」権限をグループに付与します。あなたが「groupX」グループのメンバーであるがファイルの所有者ではない場合、これらの権限はあなたに適用されます。
この場合、あなたは実際にファイルの所有者であると仮定します。所有者に設定された権限のみがお客様に適用されます。もちろん、所有者はファイルの権限を上書きまたは変更できます。しかし、グループはこれを行うことができませんでした。たとえば、vim は書き込み権限はありませんが、所有者に属するファイルに書き込んでいることを確認するように求めます。
私は通常左から右に権限を読みます。私は所有者ですか?その場合、所有者権限が適用されます。そうでなければ、私はグループのメンバーですか?その場合、グループ権限が適用されます。それ以外の場合は、「その他」の権限が私に適用されます。
場合によっては、ファイルの所有者ですが書き込み権限がないと便利です。誤ってファイルを削除または変更するのを防ぎます。個人的には、誤ってファイルを変更しないようにするために、すべてのテンプレートファイルに対して権限400を設定しました。実行権限も同様です。
答え4
ユーザーをグループに追加し、ディレクトリ(070)に対するグループ権限を付与し、再起動後にフォルダにアクセスできました。
グループの作成:sudoグループグループ名を追加
グループにユーザーを追加する:sudo gpasswd -aユーザー名グループ名
ディレクトリ全体が正しいグループ所有権の下にあることを確認してください(実行するには、グループ名の現在のメンバーである必要があります)。sudo chgrp -Rグループ名ディレクトリパス/
フォルダのグループrwxのみを提供します(rwでも可能で、必要に応じて調整)。sudo chmod -R 070 ディレクトリパス
上記をすべて完了してから必ずログアウトしてから再度ログインしてください。それでも問題が解決しない場合は、コンピュータを再起動してください。これは私にとって効果的です。