«前の日記(2010年10月02日) 最新 次の日記(2010年10月04日)» 編集

だめだめ日記

ツッコミの内容は検索サイトからの検索やサイトのレーティングに影響します。そのため問題があるキーワードを含むと思われるツッコミについては、当方の判断で削除することがあります。予めご了承ください。 なお、コメントspamと判断されたツッコミは自動的に消去されます。ご容赦ください。
2002|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|05|06|09|10|11|12|
2013|01|02|02|03|08|09|
2014|01|
2015|09|10|11|
2016|01|04|

執筆、翻訳などに関わった書籍類


【改訂新版】Samba [実践]入門

Linux教科書
LPICレベル3 300試験

マスタリング Nginx

実践 パケット解析 第2版

改訂版 Sambaのすべて

アンドキュメンテッド
Microsoftネットワーク

その他の書籍は だめだめ日記のおみせ@本店でどうぞ。



2010年10月03日 [長年日記]

[Samba]パーミッションrwxのファイルについてのACLの割り当てについて

いまさら気づくのもアレですが、Samba 3.3系列からパーミッション「rwx」のACLへの割り当てがフルコントロールではなくなってました。

理由については[Samba] Question concerning file permissions in Samba 3.3.4でJeremy氏から説明されています。

私訳

質問

Samba 3.3.4をRHEL5上でActive Directory認証を用いて動作させています。

ディレクトリに対しては、NTFSの「フルコントロール」アクセス許可を付与できますが、ディレクトリ内にあるファイルに対してはできません。何かのデフォルト設定が影響しているのでしょうか。事象が発生しているのは、共有のトップですが……

回答

まず、これは仕様です。Samba 3.3系列からは、ファイルアクセスに関する制御全般について、返却される(POSIX ACLにマッピングされた)Windowsのアクセス許可を用いる形に変更しました。

これにより、Windowsの挙動により近い処理が実現できますが、注意すべき点が1つあります。「フルコントロール」には、ファイルの削除権が含まれていますが、POSIXにおいて、ファイルの削除権は、ファイル自体ではなく、ファイルが含まれるディレクトリの権限に依存しています。

そのため、「rwx」が設定されたファイルのパーミッションをWindowsのアクセス許可として返却する際に、デフォルトでは「フルコントロール」にマッピングしたいところですが(acl map full controlのデフォルト設定を参照のこと)、付与されていないパーミッションである以上、マッピングからDELETE_ACCESSフラグを削除する必要があります。

これにより、ACLエディタでは「DELETE_ACCESS」が付与されていないため、「フルコントロール」とはみなされなくなります。

DELETE_ACCESSビットを削除しなかった場合、クライアントがopen for delete呼び出しを行い、ファイルのハンドルを取得して、set file infoコール(ファイルの削除)が呼び出された際に、削除が失敗します。

Windowsクライアントでは、open for delete呼び出しのエラーしかチェックしておらず、実際に削除を行うset file info 自体のエラーはチェックしていないません。

結果として、Windowsエクスプローラはエラーを無視してしまうため、ファイルの削除が一見成功しているにも関わらず、実際のところファイルは依然存在しています。ディレクトリの再表示が行われた際にファイルが再び表示されてしまうため、ユーザが混乱してしまいます。

上記が「フルコントロール」へのマッピングから、DELETE_ACCESSビットを削除する必要があることの説明になっていれば幸いです。ユーザを若干混乱させる点はありますが、削除したはずのファイルが黄泉から復活してしまって驚愕させるよりはマシでしょう(信じて頂きたいのですが、わたしがこの暫定対処策を見付けるまで、*非常に*長期間にわたり、この問題について多くの苦情が寄せられています)。

Jeremy

原文

Question

We're running Samba 3.3.4 on RHEL 5 Linux, using Active Directory authentication.

I've noticed that we are able to assign NTFS "Full Control" permissions to directories; however, we are unable to do the same on the files contained within those directories. Is there a default setting that is preventing us from being able to assign them? Note that this happens even at the very top of the directory tree...

Answer

Ok, here is the deal. With Samba 3.3.x, we moved to using the returned Windows permissions (as mapped from POSIX ACLs) to control all file access. This gets us closer to Windows behavior, but there's one catch. "Full Control" includes the ability to delete a file, but in POSIX the ability to delete a file belongs to the containing directory, not the file itself.

So when we return the Windows permissions for a file ACL with "rwx" set, by default we'd like to map to "Full Control" (see the default setting of the parameter acl map full control) but we must remove the DELETE_ACCESS flag from the mapping, as that is not a permission that is granted. Thus the ACL editor doesn't see "DELETE_ACCESS" in the returned ACE entry, and so doesn't believe it's "Full Control".

If we don't remove the DELETE_ACCESS bit, the client will open a file for delete, and successfully get a file handle back, but the delete will fail when the set file info (delete this file) call is made. Windows clients only check the error return on the open for delete call, not the actual set file info that allows the delete - if you fail that call Windows explorer silently ignores the error, tells you you have deleted the file, but the file is still there and will reappear on the next directory refresh, thus confusing users.

Hopefully this explains why we can't map completely into "Full Control" but must remove the DELETE_ACCESS bit. It may confuse users a bit, but that's better than confusing them when they're wondering why files they've deleted keep coming back from the dead (trust me, people complained more about that for a *long* time until I discovered this work-around).

Jeremy


Copyright (C) 2003-2017 TAKAHASHI, Motonobu
webmaster@monyo.com