web-dev-qa-db-ja.com

Windowsユーザーは、CIFS / SMB共有上のファイルのNFSv4 / Solaris ACLアクセス許可を上書きできます（フルアクセスを許可します）。これを防ぐにはどうすればよいですか？

Windowsクライアントで正しく機能するNFSv4ACLを使用するSolarisカーネルモジュールを使用して、OmniOSサーバーでSMB/CIFSファイル共有を設定しています。

次の目標で共有ディレクトリを作成したいと思います。ユーザー（たとえば、alice）はファイルを作成および変更できる必要がありますが、ファイルは削除できません。また、サブディレクトリの作成を防止する必要があります。読み取りアクセスを許可する必要があります。

基本的に機能する次のACLを試しました。

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

ただし、aliceがWindowsエクスプローラーで新しく追加されたファイルのセキュリティタブを表示すると、彼女は自分自身にフルアクセス権を付与し、後でファイルを削除できます。 Co権限がありません。

この動作を説明する方法は？また、ACLを変更できないように変更するにはどうすればよいですか？

編集：lsの出力は正常のようです：

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

ディレクトリ自体のlsの出力：

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

共有のファイルシステムはZFSです。最も興味深いデフォルト以外のプロパティは次のとおりです。

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

CIFS共有アクセス許可は、すべてのユーザーにフルアクセスを許可するように設定されているため、ファイルアクセス許可のみを適用する必要があります。

更新：

このスレッド 私の問題と非常によく似ていますが、すべての人に対して/pool/share/.zfs/shares/testshareのACLをmodify_setに減らす（またはユーザー固有の削除権限を拒否する）解決策は機能していないようです。私の場合、理由はわかりません。

windowspermissionssolariszfsaccess-control-list
4
user121391

この問題を1週間無視した後、突然機能します...原因はわかりませんが、機能します... このブログ からの提案を試しましたが、変更しました権利としてAWを含める。次に、もう一度テストしましたが、今回は古い拒否ルール（新しいルールを完全に上書きする）でのみ機能しました。最後に、私自身の質問の最初の設定を使用しましたが、これは機能しませんでしたが、現在は機能しました。

さらにテストを行った結果、SMBサービスが以前に再起動されておらず、共有ACLが正しく認識されなかったことが原因だと思います。古い（間違った）復元方法は、ACLを変更することだけでした。動作。

したがって、将来の参照のために、解決策はファイル自体に通常のアクセス許可を定義し、共有レベルでCoアクセス許可を許可しないことです。

  1. 次のACLルールをディレクトリと（継承された）すべての新しく作成されたファイルに適用します。

    /usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

  2. 次のACLルールをZFSデータセットの非表示の共有ディレクトリに適用します（これは、所有者がACLを変更できないようにするために必要です。詳細については、@ embeddedの回答とリンクされたサーバー障害の投稿を参照してください）。

    /usr/bin/chmod A=\
user:root:full_set:-------:allow,\          # root has full access
everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
/pool/share/.zfs/shares/testshare

  3. SMBサーバーを再起動します（変更された共有ACLを更新する必要があります。 このスレッド を参照）：

    svcadm restart svc:/network/smb/server:default # restart service
svcs -xv svc:/network/smb/server:default       # check if the startup date has changed

これで、新しいファイルを作成および書き込みできますが、削除することはできません。また、Windowsユーザーは自分自身に追加の権限を与えることもできません。このソリューションは私の状況ではうまく機能しますが、2つの小さな欠点があります。

  • 将来、追加のアクセス許可を設定する必要がある場合は、共有レベルを変更したことを覚えておく必要があります。
  • ユーザーがドキュメントのコンテンツを変更する可能性があります。たとえば、aliceはテキストドキュメントの文字や行を上書きできます。これは、使用するアプリケーションに追加と書き込みの権限が必要であり、「初期書き込みのみ」などをチェックするACLがないためだと思います。
1
user121391

ユーザー、グループ、全員の些細なACLを削除すると、私見ではすべてが本当に混乱します。考慮事項：

  • 許可を拒否する場合、またはファイルへのアクセス許可がない場合、特権サブシステムは、ファイルの所有者またはスーパーユーザーに許可されるアクセス要求を決定します。このメカニズムにより、ファイルの所有者がファイルからロックアウトされるのを防ぎ、スーパーユーザーが回復目的でファイルを変更できるようにします。
  • POSIXドラフトベースのACLは、単一のエントリを使用して、許可されるアクセス許可と拒否されるアクセス許可を定義します。新しいACLモデルには、アクセスチェックに影響を与える2種類のACEがあります。ALLOWとDENYです。
  • ファイルの所有者には、許可が明示的に拒否されている場合でも、無条件にwrite_acl許可が付与されます。
  • ファイルのアクセス許可を変更すると、それに応じてファイルのACLが更新されます。さらに、ファイルまたはディレクトリへのアクセスをユーザーに許可した重要なACLを削除した場合でも、グループまたは全員にアクセスを許可するファイルまたはディレクトリのアクセス許可ビットがあるため、そのユーザーはファイルまたはディレクトリにアクセスできます。

したがって、私のアプローチは、必要に応じて簡単なACLを変更し（拒否モードを使用）、すべての特別なユースケースに重要なACLを追加することです。これも覚えておいてください：

  • 許可許可が付与された後は、同じACL許可セット内の後続のACL拒否エントリによって拒否することはできません。

OmniOSが何であるかわからないが、これらのドキュメントはNFSACLを理解するのに役立ちました。 SolarisとZFSを使用しています https://docs.Oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

1
embedded