Chapter 16. ファイル、ディレクトリと共有のアクセス制御
Prev | Part III. 詳細な設定方法 | Next

## Chapter 16. ファイル、ディレクトリと共有のアクセス制御

### John H. Terpstra

Samba Team

`<jht@samba.org>`

### Jeremy Allison

Samba Team

`<jra@samba.org>`

### Jelmer R. Vernooij

drawing
The Samba Team

`<jelmer@samba.org>`

May 10, 2003

慣れたMicrosoft Windowsユーザは、期待しているようにはSamba経由で共有されている、ファイル、ディレクトリと共有リソース操作が動かないことに、しばしば当惑する。Microsoft Windowsネットワーク管理者は、ネットワークのアクセス制御と、未認証のアクセスからリソースを保護する時に、ユーザが必要とするアクセスを提供する方法についてしばしば当惑している。

多くのUNIX管理者は、Microsoft Windows環境には慣れておらず、ファイルとディレクトリのアクセスパーミッションを設定しようとするMicrosoft Windowsユーザが望むことを図式化することに困難が生じている。

問題は、2つの環境の間で、ファイルとディレクトリのパーミッションと制御がどのように動くかの違いにある。この違いは、その大きな違いに橋を架けようとしても、Sambaが完全にはそれを隠せないということにある。

POSIX ACL技術は、現在有意義な使用の例があまりないにもかかわらず、長い期間UNIX用に(拡張属性と共に)提供されてきている。これは、商用Linux製品で、ACLの適用が遅い理由について、ある程度の説明になる。Microsoft Windows管理者にとっては、Microsoft Windows NTにおいて10年以上も前から基本的な機能としてACLが提供されていることを鑑みると、このことは驚くべきことである。

この章の目的は、Microsoft Windowsデスクトップユーザに対して、最も良い環境を提供するための、最適の方法を見つけるためにネットワーク管理者を手助けする、Samba-3で可能な、各制御の要点を提供することである。

これは、異なったOS環境での相互運用性とデータの交換を提供するためにSambaが作成したことを説明するのに良い機会である。SambaはMicrosoft WindowsのようなプラットフォームにUNIX/Linuxを変化させるつもりはない。その代わり、2つの環境間で、十分なレベルでデータの交換を提供することを目的としている。現在利用可能なものは、当初の計画と希望から大きく拡大していているが、それでもギャップは縮み続けている。

## 機能と利便性

Sambaはファイルシステムアクセス管理に多くの自由度を提供する。現在のSambaでは キーとなるアクセス制御機能が提供されている:

Sambaアクセス制御機能

- UNIXのファイルとディレクトリのパーミッション

  SambaはUNIXファイルシステム制御を実装し、それを使う。Samba サーバにアクセスするユーザは特定のMicrosoft Windowsユーザとして そうする。この情報はログオンか接続のセットアップ手順の一部として Sambaサーバに渡される。Sambaはこのユーザ識別情報を、ファイル システムリソース(ファイルとディレクトリ)へのアクセス許可を与える かどうかを検証するために使う。この章では、UNIXパーミッションと 制御が少々奇妙か未知な人について、概要を提供する。

- Sambaの共有定義

  共有の設定と制御を`smb.conf`ファイル中で設定するとき、ネットワーク 管理者は本来のファイルシステムのパーミッションと動作を上書き設定 することが出来る。これはMicrosoft Windows NTユーザがより期待する ような動作を引き起こすために有用かつ便利であるが、それに到達する 最も良い方法は滅多にない。基本的なオプションと テクニックはここで説明されている。

- Sambaの共有のACL

  共有それ自身に対するACLの設定がMicrosoft Windows NTで可能なように、 Sambaでもそれは可能である。この機能を使う人は少ないが、アクセス 制御(制限)に影響を与えるために簡便な方法の一つとして残っている ことと、他の方法と比較して最小の影響でしばしばそれを行うことが できる。

- UNIX POSIX ACLを経由したMicrosoft Windows ACL

  UNIX/Linux上でPOSIX ACLを使う場合は、ベースとなるOSがそれをサポート している場合にのみ可能である。もしもそうでない場合、このオプションは 有効ではない。現在のUNIX技術基盤ではPOSIX ACLを標準サポートしている。 このサポートを提供するLinux kernelへのパッチも存在する。残念なことに、 Linuxプラットフォームの一部のみがネイティブなACLと拡張属性を有効にして 現時点で提供を行っている。この節では、それをサポートしているプラット フォームのユーザに対する関連情報が記述されている。

## ファイルシステムのアクセス制御

おそらく、最も重要な認識される点は、UNIX OS環境で提供されているものと、Microsoft Windows NT4/200x/XPにおけるフィルシステムの技術の実装が完全に異なるという単純な事実である。最初に最も有意義な違いが何かを考え、次にその違いを乗り越えるためにSambaが何をしているかを見てみることにする。

### Microsoft Windows NTFSとUNIXファイルシステムとの比較

SambaはUNIXファイルシステムの上で動作する。これは、UNIXファイルシステムの 取り決めとパーミッションの適用を受けることを意味する。また、もしも Microsoft Windowsネットワーク環境がファイルシステムの動作を要求するならば、 それはUNIXファイルシステムの動作とは異なり、何らかの方法でSambaは透過的かつ 一貫した方法でエミュレートを行う。

Sambaがこれをかなりの部分、それらの最上位で、既定値の動作を上書きする高度な オプションの設定を提供するという良いニュースがある。いくつかの上書きについて 説明はあるが、大部分は既定値の動作の範囲内にとどまっている。制御可能性の詳細な 点について知りたい場合は、`smb.conf`マニュアルページを調べること。

以下では、UNIXファイルシステムの機能とMicrosoft Windows NT/200xを比較する:

名前空間

  Microsoft Windows NT4/200x/XPのファイル名は254文字まで有効だが、UNIX ファイル名は1023文字まで大丈夫かもしれない。Microsoft Windows中で、 ファイルの拡張子は特定のファイルタイプを意味する。UNIXではすべての名前が 任意であると考えられるので、これは厳格には見かけない。

  Microsoft Windowsがフォルダと読んでいるものは、UNIXではディレクトリである。

大文字小文字の区別

  Microsoft Windowsファイル名は8.3形式(8文字のファイル名と3文字の拡張子)の 場合、一般的に大文字である。8.3形式より長いファイル名は、大小文字を保持 するが、それは無視される。

  UNIXのファイルとディレクトリ名は大文字小文字を区別し、その状態は保存 される。SambaはMicrosoft Windowsファイル名の動作を実装しているが、それは ユーザアプリケーションとしてである。UNIXファイルシステムは大文字小文字を 無視したファイル名の検索を実行する機能は提供していない。Microsoft Windows はこれを既定値で行う。これは、UNIX OS環境で標準としては備わっていない 機能を提供するために、処理のオーバヘッドがかかってしまうと言うことである。

  以下の例を考えてみる。以下はUNIX名としては一意だが、Microsoft Windows ファイル名としては同一である:

      				MYFILE.TXT				MyFile.txt				myfile.txt

  明らかに、Microsoft Windowsファイルの名前空間ではこれらの3つのファイルは 同時に存在できないが、UNIXではできる。

  もしも上記3つがすべて存在していたときにSambaは何をすべきか? 辞書的に最初のものがMicrosoft Windowsユーザから見えるようにすることで ある。残りは見えず、アクセスも出来ない。それ以外の解は自殺的 行為である。Windowsクライアントは大文字小文字を区別しないファイル検索を 要求するため、大文字小文字を区別しないファイルの一覧に一致する、 複数のファイルがあるUNIXディレクトリの場合、Sambaは一貫した選択方法を 提供しなければならないということになる。

ディレクトリの区切り文字

  Microsoft Windows とDOSはディレクトリの区切り文字としてバックスラッシュ `\`を使い、UNIXでは通常のスラッシュ`/` をディレクトリの区切り文字として使う。これはSambaによって透過的に扱われる。

ドライブの識別

  Microsoft Windows製品は、ディレクトリのパーティションを表現するために、 `C:`のようなドライブレターの概念を持つ。UNIXはファイルの パーティションに対して分離された識別子を持つという概念がない。そのような 各ファイルシステムはディレクトリツリー全体の一部としてマウントされる。 UNIXディレクトリツリーは、`C:\`のような、DOSの ドライブのrootを指定するような形で、`/`から始まる。

ファイル名に関する規則

  Microsoft Windowsは一般的に先頭がドット(`.`)で始まる ファイル名は使わないがUNIXの場合、はユーザのホームディレクトリ中では 当たり前のように使われている。ドット(`.`)で始まる ファイルは通常多くのUNIXアプリケーションの起動ファイルか、スタートアップ 設定データを含むファイルである。

リンクとショートカット

  Microsoft Windowsは、実際の位置にあるファイルに対してそのファイルを実行する ためにリダイレクトを行う、特別なタイプのファイルとして振る舞う リンクとショートカットを使う。UNIXでは、ファイルと ディレクトリのリンクを使うが、それはMicrosoft Windowsユーザが使っているもの とは全く異なる。

  シンボリックリンクは、UNIX中ではデータ(ファイル又はディレクトリ)の実際の 位置を含むファイルである。(読み出しあるいは書き込みのような)操作は参照 されたファイルに対して直接行われる。シンボリックリンクは “ソフトリンク”としても参照される。ハードリンクはMicrosoft Windowsではなじみのないものである。これは、1つの物理的なファイルを、複数の ファイル名で同時に参照できるようにするものである。

Microsoft Windows管理者が、UNIX/Linuxを理解するようになるプロセス中で、一時的に 若干当惑することを引き起こすかもしれな微妙な違いがある。それらは、UNIX/Linuxの トレーニングと教育の目的としての専用のテキストを見ると良い。

### ディレクトリの管理

ディレクトリ操作には3つの基本的な操作がある。それは`作成`, `削除`,`改名`である。 UNIXとWindowsによるディレクトリの管理 では、WindowsとUNIX中でのコマンドにおける、上記の操作の実装について比較している。

Table 16.1. UNIXとWindowsによるディレクトリの管理

動作 | Microsoft Windowsのコマンド | UNIXのコマンド
--- | --- | ---
create | md folder | mkdir folder
delete | rd folder | rmdir folder
rename | rename oldname newname | mv oldname newname

### ファイルとディレクトリのアクセス制御

ネットワーク管理者は、ファイルとディレクトリのパーミッションのメンテナンスに 関連する、基本的なUNIX学習マニュアルとリファレンス資料を読むことを強く推奨する。 POSIX ACLや拡張属性(EA)のようなより複雑な機能に訴求しない基本的なUNIXの パーミッションについて多くの説明がある。

UNIX/Linuxのファイルとディレクトリアクセスパーミッションは3つの主要なデータの設定と 1つの制御の設定がある。UNIXでのファイル一覧は下記のようになる:

    $ ls -latotal 632drwxr-xr-x   13 maryo   gnomes      816 2003-05-12 22:56 .drwxrwxr-x   37 maryo   gnomes     3800 2003-05-12 22:29 ..dr-xr-xr-x    2 maryo   gnomes       48 2003-05-12 22:29 muchado02drwxrwxrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado03drw-rw-rw-    2 maryo   gnomes       48 2003-05-12 22:29 muchado04d-w--w--w-    2 maryo   gnomes       48 2003-05-12 22:29 muchado05dr--r--r--    2 maryo   gnomes       48 2003-05-12 22:29 muchado06drwsrwsrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado08----------    1 maryo   gnomes     1242 2003-05-12 22:31 mydata00.lst--w--w--w-    1 maryo   gnomes     7754 2003-05-12 22:33 mydata02.lst-r--r--r--    1 maryo   gnomes    21017 2003-05-12 22:32 mydata04.lst-rw-rw-rw-    1 maryo   gnomes    41105 2003-05-12 22:32 mydata06.lst$

1行の中の各項目は(左から右に)パーミッション、ファイルのハードリンク数、所有者、 グループ、サイズ(バイト)、アクセス日付、最終更新日付とファイル名である。

パーミッション欄の概要はUNIXパーミッション欄の概要 にある。

Figure 16.1. UNIXパーミッション欄の概要

どのビットフラグもOFFにできる。OFFになったフラグは"できない"と同値で、 “-”文字で表現される(“サンプルファイル”を参照)。

Example 16.1. サンプルファイル

    -rwxr-x---   意味:  ^^^                所有者(ユーザ)はこのファイルを読み、書き、実行できる。    ^^^             グループに属したユーザは読み、実行できる。       ^^^          それ以外のユーザはこのファイルに対して何も出来ない。

[タイプ]フィールドにはさらに別の意味もあり、それは、c = キャラクタデバイス、 b = ブロックデバイス、p = パイプデバイス、s = UNIXドメインソケットである。

文字`rwxXst`はユーザ、グループとその他に対して、読み出し(r)、 書き込み(w)、実行(あるいはディレクトリへのアクセス許可) (x)、ファイルが ディレクトリかすでにあるユーザに対して実行許可を与えられた場合に実行可能(X)、 実行時にset user ID (SUID)か set group ID (SGID) (s)かスティッキー(t)である。

スティッキービットがディレクトリ上に設定された場合、そのディレクトリ内にある ファイルは、rootか所有者のみunlink(削除)か改名できる。スティッキービットがない 場合、書き込み可能なディレクトリでは、誰でもファイルの削除や改名が出来る。 スティッキービットは、誰でも書き込み可能な、`/tmp`のような ディレクトリでは一般的に使われる。

setuidやsetgidビットがディレクトリに設定された場合、その中に作成された ファイルは、setuidビットsetgidビットのいずれが設定されたかに応じて、ディレクトリの 所有ユーザたはグループによって所有される。これは、あるグループに所属している すべてのユーザがファイルの読み書きをできるようにすることが望ましく、これらの ユーザが所属しているものと異なるプライマリグループを持つユーザが、該当の ファイルを排他的に所有してしまうことが望ましくないようなディレクトリの パーミッションを設定する際に有効なことがあろう。

ディレクトリが`d-wx--x---`に設定された時、所有者はその中の ファイルを読んだり作成(書き込み)出来るが、読み出し(r)フラグが設定されていない ので、だれも、ファイルの一覧を表示(見る)事が出来ない。グループに属するユーザは そのディレクトリ中のファイルを読めるが新しいファイルは作成できない。もしも、 ディレクトリ中のファイルがグループに対して読み書き可能なように設定された場合、 グループメンバはそれらに書き込み(または削除)ができる。

#### ディレクトリとファイルの削除操作からの保護

どのように、ユーザの削除操作から、ファイルやディレクトリを保護したらよいか、 という事についてSambaメーリングリストに質問が来ることがある。例えば、Windows NT/2K/XP は、ディレクトリ配下に、ファイルを書くことは出来るが削除できないというアクセス制御を 設定する機能がある。これは、ファイルに書き込みは出来るが、削除は出来ないというACLを Windows上で設定することで可能になる。このような考え方はUNIX OSファイル空間ではない。 UNIXファイルシステムでは、ファイルを作成出来るユーザはファイルに書き込みが出来る。 ファイルがあるディレクトリへの書き込み権があり、ファイルへの書き込み権があるユーザは それを削除できてしまう。

確認ではあるが、UNIX環境では、ファイルの削除はそのファイルがいるディレクトリの パーミッションによって制御される。別の言い方をすると、対象となるファイルの 所有者ではなくても、書き込み権があるユーザは、ディレクトリ中のファイルを 削除できる。

必要に応じて、SambaはホストOSのファイルシステムの構造を受け取る。Sambaは Windows ACLを有効にすることについてと"最も最適な"POSIX ACLへの変換実行に ついては、ファイルシステムの能力に制限される。いくつかのUNIXファイルシステム では、拡張属性と呼ばれている機能をサポートしている。Windowsでの 継承という概念のみ、適切な拡張属性を使ってSambaは 実装している。

拡張属性の特定の動作は、UNIXと例えばLinuxのようなUNIX風のシステム全体には 一貫していない。例えば、ディレクトリやファイルを削除操作から防ぐためのフラグを セットすることは、拡張属性の特定の実装では可能である。これを達成する拡張属性は `immutible`ビットと呼ばれている。残念なことに、immutible フラグの実装は公開された文書とは一致していない。たとえば、SuSE Linux 9.2上の `chattr`のマニュアルには:

    A file with the i attribute cannot be modified: it cannot be deletedor renamed, no link can be created to this file and no data can bewritten to the file. Only the superuser or a process possessing theCAP_LINUX_IMMUTABLE capability can set or clear this attribute.(訳: i 属性を持つファイルは変更できない:削除も改名もこのファイルへのリンク作成も出来ないし、このファイルへの書き込みも出来ない。スーパーユーザかCAP_LINUX_IMMUTABLE機能を所有するプロセスがこの属性を設定および削除できる)。

immutible flag が、Sambaが動いているファイルシステム上でサポートされているか、 簡単なテストは以下のように出来る。

Procedure 16.1. ファイルの Immutibilityサポートのテスト

1. `filename`という名前のファイルを作成。

2. `root`ユーザとしてログインし、以下のようにimmutibileフラグをテストファイルに設定:

       root#  chattr +i `filename'

3. ファイルを所有しているユーザ(非root)でログインし、以下のようにしてファイル削除を試みてみる:

       mystic:/home/hannibal > rm filename

   immutibleが正しく効いているならばファイル削除は出来なくなっている。

immutible bitをサポートしているファイルシステムがあるOS上では、ディレクトリを 作成できるが削除できないようにするのは可能である。immutableディレクトリが書き込み 可能かどうかを、そのホストシステム上のマニュアルページでチェックすること。 もしも出来なければ、ディレクトリ全体とその内容は、書き込み(ファイル作成も)と 削除から効果的に保護される。

## 共有のアクセス制御の定義

`smb.conf`セクション中の以下のパラメータは、共有の制御かアクセス制御の設定を 定義する。以下のオプションのどれかを使う前に、`smb.conf`のマニュアルページを 参照のこと。

### ユーザとグループベースの制御

ユーザとグループベースの制御はとても便利なことがわかっている。ある特定の状態に おいては、単一のユーザが行うような形で、すべてのファイルシステムへの操作を強制する ことはとても望ましいことがある。force userと force groupの動作を使うとこれを行う事ができる。 他の状態においては、特定の認証された人のみが共有またはその内容にアクセス出来る ようにさせるような、偏執的なレベルの制御を使うことが必要かもしれない。これには、 valid usersかinvalid users パラメータが便利である。

いつものように、管理するためと、アクセスを制御する方法の不明確な点を最小化する、 一番簡単な方法を使うことを特に推奨する。覚えていてほしいが、状態をそのまま残すと、 他の誰かが手助けを提供する必要があり、もしもだれかが、あまりにも大きな混乱状態 を見つけるか、何をしていたかが理解できない場合、Sambaが削除され、別の解が適用 されてしまうと言う危険性が出てくる。

ユーザとグループベースの制御は上記の制御について列挙している。

Table 16.2. ユーザとグループベースの制御

制御パラメータ | 説明、動作、備考
--- | ---
admin users | 共有に対して管理者権限を許可するユーザの一覧。そのユーザは スーパーユーザ(root)と同様すべてのファイル操作ができる。 この一覧中のユーザは共有上でファイルのパーミッションに関わらず 何でも出来る。
force group | このサービスに接続するすべてのユーザに既定値のプライマリグループ として割り当てるUNIXのグループ名を指定する。
force user | このサービスに接続するすべてのユーザに既定値のユーザとして 割り当てるUNIXのユーザ名を指定する。 これは、ファイルの共有に便利である。間違って使うとセキュリティ 上の問題が発生する。
guest ok | もしもパラメータがサービスに対して接続されたならば、サービスに 接続する時にパスワードが不要になる。権限は guestアカウントになる。
invalid users | このサービスにログイン出来ないユーザのリスト。
only user | 接続を許可しないユーザ名の一覧。
read list | サービスに対してリードオンリアクセスを許可するユーザの一覧。 この一覧中のユーザはリードオンリオプションがどのように設定 されていても、書き込み権はない。
username | 詳細は`smb.conf`マニュアルページを参照。これは複雑で潜在的に 間違って使われるパラメータである。
valid users | サービスにログイン出来るユーザの一覧。
write list | サービスに読み書き可能なアクセスが出来るユーザの一覧。

### ファイルとディレクトリに対するパーミッションベースの制御

ディレクトリパーミッションベースの制御は、間違って使った場合、間違った設定の 原因を診断するのにかなりの困難が生じる。控えめに、そして厳重に使うこと。 徐々に、1つずつ、おのおのを導入すると、好ましくない副作用が見つかるかもしれない。 問題発生時には、いつでもそれらをコメントアウトし、徐々に様子を見ながらそれらを 元に戻していく。

ファイルとディレクトリパーミッションベースのアクセス制御を使うためのパラメータに 関連する情報は、 ファイルとディレクトリパーミッションベースの制御 を参照のこと。

Table 16.3. ファイルとディレクトリパーミッションベースの制御

制御パラメータ | 説明、動作、備考
--- | ---
create mask | `smb.conf`マニュアルページを参照のこと
directory mask | UNIXディレクトリを作成する時に、DOSのモードをUNIXのモードに 変換する時に使う8進のモード値。directory security maskも参照。
dos filemode | このパラメータを有効にすると、ファイルに書き込み権があるユーザに そのパーミッションの変更を許可する。
force create mode | このパラメータは、Sambaによって作成されたファイル上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。
force directory mode | このパラメータは、Sambaによって作成されたディレクトリ上に常時設定 されるUNIXモードのビット単位のパーミッションを指定する。
force directory security mode | Windows NTクライアントがディレクトリ上のUNIXパーミッションを操作 する時に変更されるUNIXパーミッションビットを制御する。
force security mode | Windows NTクライアントがUNIXパーミッションを操作する時に変更 されるUNIXパーミッションビットを制御する。
hide unreadable | 読めないファイルを、クライアントから見えなくする。
hide unwriteable files | 書き込めないファイルをクライアントから見えなくする。書き込めない ディレクトリは通常通り見える。
nt acl support | このパラメータはsmbdがUNIXパーミッションをWindows NT ACLにマップ するかどうかを制御する。
security mask | Windows NTクライアントがファイル上のUNIXパーミッションを操作する 時に変更されるUNIXパーミッションビットを制御する。

### その他の制御

他の制御中に記載があるパラメータはファイルアクセスへの 不注意によるバリアを作成する方向で、管理者によってしばしば使われる。それらは、 `smb.conf`のファイル設定の完全な影響がわからない結果である。The parameters documented in Other Controls are often used by administrators in ways that create inadvertent barriers to file access. Such are the consequences of not understanding the full implications of `smb.conf` file settings.

Table 16.4. 他の制御

制御パラメータ | 説明、動作、備考
--- | ---
case sensitive, default case, short preserve case | これは、すべてのファイル名検索を大文字小文字を意識した形で行う 事を意味する。Microsoft Windowsくらい亜入おから受け取った正確な 名前で、ファイルはSambaによって作成される。
csc policy | クライアントサイトのキャッシングポリシーは、Microsoft Windowsの クライアントサイドのファイルキャッシング機能に類似している。
dont descend | 常時空白としてサーバが見せる、カンマで分離されたディレクトリ一覧を指定する。
dos filetime resolution | このオプションは、Samba共有に対して、主にVisual C++との互換オプションとして使われる。
dos filetimes | ファイルに書き込みが出来るときにDOSとWindowsは、ユーザにファイルの 時刻変更を許可する。POSIXでの流儀ではこれは出来ない。このオプションは DOSとWindowsの流儀を許可する。
fake oplocks | Oplocksは、SMBクライアントがサーバから、ファイル操作をローカルに キャッシュする許可を得る方法である。もしもサーバがoplockを許可 すると、クライアントは、ファイルへのアクセスが唯一であると仮定 することから自由になり、ファイルのデータをより頻繁にキャッシュする。
hide dot files, hide files, veto files | 注意:Microsoft Windowsエクスプローラはhiddenが設定されたファイルの 状態を無視するので、結局それは見えてしまう。
read only | このパラメータがyesの場合、サービスのユーザはサービスのディレクトリ 中のファイルを作成又は変更できない。
veto files | 見えないか、アクセスできないファイルとディレクトリの一覧。

## 共有のアクセス制御

この節では、Sambaの共有単位でのアクセス制御における制限の設定方法について取り 扱う。既定値では、Sambaは共有自身には何らの制限も設定しない。共有自身への 制限は、Microsoft Windows NT4/200x/XP共有上で設定出来る。これは、共有に 接続する人を効果的に制限できる方法である。特定の制限がない場合、既定値の 設定はグローバルユーザに対して`Everyone - フルコントロール` (フルコントロール、変更と読み出し)である。

現時点ではSambaは共有上のアクセス制御の設定を行うためのツールを提供していない ので、それらの設定を作成する唯一の方法は、NT4のサーバマネージャか Windows 200xの、コンピュータの管理のための、Microsoftマネジメントコンソール (MMC)を使うことである。Sambaのコマンドラインツールでこの機能を提供することは 現時点では予定されていない。

Sambaは`share_info.tdb`というファイル中に共有単位のアクセス 制御の設定を格納する。サーバ上にこのファイルがある場所は、Sambaがコンパイル された状態に依存する。Sambaのtdbファイルがある既定値の位置は、 `/usr/local/samba/var`配下である。もしも`tdbdump` ユーティリティがコンパイルされシステム中にインストールされているならば、 tdbファイルがあるディレクトリ中で`tdbdump share_info.tdb`を 実行する事によってこのファイルの内容を検査することが出来る。

### 共有のパーミッションの管理

共有のパーミッションの管理を行うための最適のツールはプラットフォーム 依存である。環境に応じて最適のツールを選択されたい。

#### Windows NT4 Workstation/Server

Windows NT4 ワークステーションかサーバからSambaサーバ上の 共有のパーミッションを管理するのに必要なツールは、 NT サーバマネージャである。サーバマネージャはWindows NT4 サーバ製品とともに出荷されているが、Windows NT4ワークステーション には付いていない。Microsoft Windows NT4 ワークステーション 用のNT サーバマネージャは、MicrosoftのWebサイト support から入手できる(訳注:日本語版はこちらから)。

Procedure 16.2. 手順

1. NT4 サーバマネージャを起動し、管理 したいSambaサーバをクリックする。メニューから コンピュータを選択し、 共有ディレクトリをクリックする。

2. 管理したい共有をクリックし、次にプロパティ タブをクリックし、パーミッションタブを クリックする。これで、アクセス制御を追加/変更できるようになる。

#### Windows 200x/XP

Microsoft Windows NT4/200x/XP上では、 共有のACLはMicrosoftエクスプローラのようなツールで設定する。 たとえば、Windows 200xでは、共有フォルダを右クリックし、次に、 共有を選択し、次に パーミッションをクリックする。 Windows NT4/200xでの既定値のパーミッションはグループ "Everyone"が共有に対してフルコントロールを持つようになっている。

Microsoft Windows 200xとそれ以降のバージョンでは、MMCに対して コンピュータの管理スナップインと 呼ばれるツールが提供されている。このツールは、 コントロールパネル->管理ツール->コンピュータの管理 経由でアクセス出来る。

Procedure 16.3. 手順

1. MMCのコンピュータマネジメントスナップインを起動後、メニュー項目 操作(A)をクリックし、 別のコンピュータに接続(C)を選択する。もしも、 ドメインにログオンしていない場合、ドメインログオンユーザ名と パスワードを聞いてくるので入力する。それでドメインの認証を行う。 もしも管理者権限でログインしているならば、このステップは省略される。

2. もしも、Sambaサーバがコンピュータを選択 ボックス中に表示されていないならば、Name: フィールド中に対象のSambaサーバの名前を入力する。次に システムツールのそばにある [+]をクリックし、左パネル中の 共有フォルダのそばにある [+]をクリックする。

3. 右パネル中でアクセス制御のパーミッションを設定したい共有上で 右クリックする。次に、共有のパーミッション を右クリックする。これで、小浮遊フォルダにアクセス制御 エンティティを追加できる。各エントリに割り当てたいアクセスの タイプ(フルコントロール、変更、読み込み)を覚えておくこと。

### Warning

注意深く作業する必要がある。このユーザを削除しないで `Everyone`ユーザからすべてのパーミッションを 取り去ると、この共有に対しては誰もアクセス出来なくなる。これは ACLの優先順位として知られていることの結果である。Everyoneに 対してアクセス権なしということは、 `Everyone`のグループに属している `MaryK`というユーザは、明示的な、フルアクセス の権利を与えられたとしても、アクセスできない。

## Microsoft Windowsのアクセス制御リストとUNIXとの相互運用性

### NTセキュリティダイアログを使用したUNIXパーミッションの管理

Windows NTクライアントは、基盤となるUNIXパーミッションを表示したり変更 するための、ネイティブなセキュリティ設定ダイアログボックスを使うことが できる。

この機能は、Sambaが動作しているUNIXホストのセキュリティを危うくしない ように留意し、かつ、Samba管理者が設定出来るすべてのファイル パーミッションルールに依然として従う。

SambaはPOSIX ACLの範囲内で動くので、種々の、Windowsで提供されている よりきめ細かいアクセス制御は実際の所無視される。

### Note

Samba経由での、UNIX/LinuxシステムファイルへのすべてのアクセスはOSの ファイルアクセス制御によって制御される。ファイルアクセスの問題を理解 しようとする時、Sambaによってファイルアクセスを行う時に提供されるWindows ユーザの識別子を見つけることはきわめて重要である。これは、Sambaのログ ファイルから見つけるのが最も良い。

### Samba共有上でのファイルセキュリティの表示

NT4/200x/XPクライアントからSambaでマウントしたドライブレターかUNCパス 中のファイルかディレクトリのどれかを右クリックする。メニューがポップ アップするのでメニューの最下部にあるプロパティ エントリをクリックする。この動作でファイルのプロパティ ダイアログボックスが上がってくる。セキュリティタブを クリックすると3つのボタンが表示される:アクセス許可、 監査と所有者である。 監査ボタンは、ユーザがNTの管理者でない場合、 "要求された権限をクライアントが持っていません(A requested privilege is not held by the client)" というエラーメッセージを表示するか、ユーザがNT管理者としてログオンしている 場合、ファイルに対する監査要求を追加するために、管理者に許可を行う ダイアログを表示する。このダイアログは現時点ではSamba共有には機能しない ので、唯一使えるボタンである 追加ボタンは、 表示されているユーザの一覧を現時点では許可出来ない。

### ファイルの所有者の表示

所有者ボタンをクリックすると、ダイアログボックスが 表示され、そのファイルの所有者を表示する。所有者は以下のように表示される:

    		SERVER\user (長い名前)

ここで`SERVER`はSambaサーバのNetBIOS名である。 `user`はこのファイルを所有しているUNIXユーザ のユーザ名であり、`(長い名前)`はユーザを識別 するための説明文字列である(通常はUNIXパスワードデータベースのGECOS フィールドが使われる)。閉じるボタンをクリック して、このダイアログを閉じる。

もしもnt acl supportパラメータが `false`に設定されているならば、ファイルの所有者は NTユーザのEveryoneとして表示される。

所有権の取得ボタンでは異動したい先の人がこの ファイルの所有権を取得することは出来ない(それをクリックすると、現在 NTクライアントにログオンしているユーザが見つからないということを通知する ダイアログボックスが表示される)。この理由は、ファイルの所有者の変更は、 UNIX上では特権操作であり、rootユーザにのみ許可されて いるからである。このボタンをクリックすると、NTに対してNTクライアントに ログオンしている現在のユーザにファイルの所有者を変更するようにNTに指示 するが、これは現時点ではSambaでは動作しない。

NTにある`chown`コマンドはSambaでも動作し、rootとして Sambaサーバに接続している管理者権限を持つユーザに、ローカルのNTFSファイル システムとリモートマウントしたNTFSかSambaドライブの両方のファイルの所有者 の変更を許可する。これは、Sambaチームの一員であるJeremy Allisonによって 書かれたNTセキュリティライブラリであるSeclibの 一部として提供されていて、これはSambaのFTPサイトからダウンロードできる。

### ファイルとディレクトリのパーミッションの表示

3番目のボタンはアクセス許可である。これをクリックすると、 パーミッションとファイルかディレクトリのUNIXでの所有者の両方を表示する ダイアログボックスが起動する。所有者は以下のように表示される:

``SERVER`\ `user` `(長い名前)``

`SERVER`はSambaサーバのNetBIOS名であり、 `user`はファイルを所有しているUNIXユーザの ユーザ名であり、`(長い名前)`は、ユーザを識別 する説明文字列である(通常はUNIXパスワードデータベースのGECOSフィールドが 使われる)。

もしもnt acl supportパラメータが `false`に設定されている場合、ファイルの所有者は `Everyone`というNTユーザとして表示され、パーミッション はNTのフルコントロールとして表示される。

パーミッション欄はファイルとディレクトリでは異なって表示される。詳細は次項で説明する。

#### ファイルのパーミッション

標準のUNIXユーザ/グループ/その他の三つ組みと、それに対応する `読み、書き、実行`パーミッションの三つ組みは、Sambaによって “r”, “w”, と “x”ビットが対応するNT パーミッションにマップされる、NT ACLのパーミッションの3つの要素にマップされる。 UNIXの「その他」パーミッションは、UNIXの世界で許可されるパーミッションのリストを 伴ってグローバルNTグループの`Everyone`にマップされる。 UNIXの所有者とグループパーミッションは、それぞれUNIXのユーザとグループに 許可されるパーミッションのリストを伴って、NTのユーザアイコンと NTのローカルグループアイコンとして表示される。

多くのUNIXパーミッションのセットが、たとえば`読み込み`、 `変更`, あるいは `フルコントロール` のような共通のNTの名前にマップしないという理由で、通常パーミッションは NTの表示リスト中で`特殊なアクセス許可`という単語が 前に付く。

しかし、もしもファイルに、特定のUNIXユーザ、グループ、その他に対して何も 許可しないパーミッションが付いているとどうなるだろうか? アクセス権なしを見えるように、かつ変更できるように するため、Sambaは`所有権の取得`というNTのACL属性を 上書きし(UNIXでは何の意味もない)、NTの`O`ビットを設定 して、アクセス権なしというコンポーネントを報告する。これはもちろん、 それを0のようにするために選ばれ、結局アクセス権なしの意味になる。 この動作の背景にある結論についての詳細は、以下に記述がある。

#### ディレクトリのパーミッション

NT NTFSファイルシステム上のディレクトリは、2つの異なったパーミッションの 組を持っている。最初の組は、通常の`RW` NT形式中での 最初の括弧の組中に表示される、ディレクトリそれ自身上のACLセットである。 このパーミッションの最初の組は通常のファイルのパーミッションに対して、 上記で説明があったようなのと正確に同じ方式で、Sambaによって作成され、 同じ方法で表示される。

2番目のディレクトリパーミッションの組はUNIXパーミッションの世界では実際の 意味を持たず、このディレクトリが継承する範囲内で作成された任意のファイルの `継承された`パーミッションを表す。

SambaはNT用にそれら継承されたパーミッションをまとめ、NT ACLとして返すので、 Sambaによって新しく作成されたこの共有のUNIXパーミッションモードを 受け取れる。

### ファイルまたはディレクトリのパーミッションの変更

ファイルとディレクトリのパーミッションの変更はダイアログボックス中に表示された パーミッションの変更と同じくらい簡単で、OKをクリック すればよい。しかし、ユーザが認識する必要がある制限があり、また、Samba標準の パーミッションマスクと注意を払わなければならない事も必要なDOS属性のマッピング も相互に影響する。

もしも、nt acl supportパラメータが`false` ならば、"アクセスが拒否されました"というメッセージが 出力されて、セキュリティパーミッションを設定することは失敗する。

最初に注意することは、追加ボタンはSamba中のユーザの一覧を 返さない事である("リモートプロ子ジャーコールは失敗し、実行出来ませんでした" というエラーメッセージが表示される)。これは、ダイアログボックス中に一覧表示されて いる、現在のユーザ/グループ/その他 のパーミッションのみを操作できると言うことで ある。これらはUNIXが実際に持っているパーミッションのみなので、これは実際にちゃん と動く。

もしもパーミッションの三つ組み(ユーザ、グループかその他のどれか)がNTダイアログ ボックス中でパーミッションのリストから削除されたならば、OK ボタンが押されたとき、UNIXサイド上ではパーミッションなし 状態になる。もしもサイドパーミッションを表示させると、NTの`O` フラグとして、上記で説明したようにパーミッションなしが表示 される。これはパーミッションの三つ組から取り去ったものをファイルかディレクトリに もういちど戻すためにパーミッションを追加できるようにする。

UNIXはNT ACLの“r”, “w”, と “x”ビットのみを サポートするため、もしも、`削除`のような他のセキュリティ属性が 選択された場合、Sambaサーバ上に適用するときには無視される。

ディレクトリにパーミッションを設定する場合、2番目のパーミッションの組(括弧の組の 二番目)は既定値でディレクトリ中のすべてのファイルに適用される。もしも、これが やりたいことではない場合、NTダイアログボックス中の Replace permissions on existing filesチェックボックスの チェックを、OKボタンを押す前に外さなければならない。

もしもすべてのパーミッションを、ユーザ/グループ/その他から取り去りたい場合、 コンポーネントをハイライトさせ、削除ボタンをクリック するか、特別な`所有権の取得`パーミッション(`O`として表示される)のみををハイライトさせてもよい。

### 標準的なSambaの“create mask”パラメータとの相互作用

標準的なSambaの`create mask`パラメータとの相互作用を制御する4つのパラメータがある:

- security mask

- force security mode

- directory security mask

- force directory security mode

ユーザがパーミッションを適用するためにOKをクリックした 時、Sambaは与えられたパーミッションを、ユーザ/グループ/その他のr/w/x三つ組 にマップし、次にsecurity maskパラメータ中で設定された ビットに対し、ファイルに対して変更されたパーミッションを検査する。このパラメータ 中で1に設定されていない変更されたすべてのビットは、ファイル パーミッション中でそのまま残る。

本質的に、security mask中のゼロビットは、ユーザが 変更を許可しないビットの組として、1のビットは変更を認めるビットとして扱っても よい。

もしも明示的に設定されていない場合、このパラメータは既定値として create maskパラメータと同じ値になる。ユーザにファイル 上のすべてのユーザ/グループ/その他 のパーミッションの設定変更を許可したいならば、 この値を0777にする。

次にSambaは、force security modeパラメート中で設定された ビットに対して、ファイルのパーミッションの変更点をチェックする。このパラメータ 中で1に設定されたものに対応する、変更された任意のビットは、 強制的にセットされる。

基本的に、`force security mode`パラメータ中でビットを設定 することは、ファイル上のセキュリティを変更する時、ユーザが常時on に設定するとして、ビットのまとまりを扱っても良い。

もしも、明示的に設定されない場合、このパラメータの既定値は、 force create modeパラメータでの値と同じになる。 何の制限もなしにすべてのユーザ/グループ/その他のパーミッションの変更を許可したい ならば、このパラメータを000に設定する。 security maskと`force security mode` パラメータはその順で、変更要求のために適用される。

ディレクトリには、`security mask`の代わりに `directory security mask`を、 `force security mode`の代わりに `force directory security mode`パラメータを使う点を除いて、 上記で説明したファイルへの操作と同じ動作をSambaは実行する。

directory security maskパラメータの既定値は、 `directory mask`パラメータと同じ値に設定され、 `force directory security mode`パラメータの既定値は、 force directory modeパラメータと同じ値に設定される。 この方法で、その制限内で引き続きパーミッションビットをユーザに変更許可する 間、Samba共有上で管理者が設定出来るパーミッションの制限を実施する。

もしも、ファイルとディレクトリ上でパーミッションビットを変更する フルコントロール権をユーザに許可するように、かつ、強制的に特定のビットを onに設定しない、共有を設定したいならば、 `smb.conf`ファイル中の共有固有のセクションに、以下のパラメータを記述する:

`security mask = 0777`
`force security mode = 0`
`directory security mask = 0777`
`force directory security mode = 0`

### 標準Sambaファイル属性のマッピングの相互関係

### Note

Sambaは(“read-only”のような)DOS属性の一部をファイルのUNIX パーミッションにマップする。これは、セキュリティダイアログ経由での パーミッションビットの設定とファイル属性マッピングによって設定されるビットとの の間に競合が生じることがでてくる。

もしも、ファイルが所有者に対して読み込み権がない場合、これは標準ファイル属性 タブダイアログ中で“読み取り専用”として表示される。都合の悪いことに、 このダイアログは、他のタブ中にあるセキュリティ情報を含むものと同じである。

これができる事が意味するものは、もしも所有者がセキュリティダイアログを使って 自分自身に読み込みを許可するためにパーミッションを修正するならば、 標準セキュリティダイアログに戻るためにOKをクリックし、 次にNTはファイルのパーミッションを読み取りのみに戻す(ダイアログ中では引き続き 表示される属性)。これは、パーミッション設定後、属性ダイアログに戻るために OKをクリックした後、変更を書き戻さないようにするため、 OKの代わりにキャンセルをクリック する事を意味する。

### Windows NT/200X ACLとPOSIX ACLの制限

Windowsの管理者は簡単なACL制御になれていて、通常UNIXのユーザ/グループ/その他(ugo) のパーミッションは不十分で十分にきめ細かくないと考えている。

競合しているSMBの実装は、Windows ACLをどのように取り扱うかについて異なる。Sambaは Windows ACLを、UNIXのファイルシステム管理の構造で取り扱い、そのため、POSIX ACLの 制限が適用される。そのため、Windows NT/200X ACLの機能が POSIX ACLには欠如している ので、POSIX ACLのセマンティックスと制限は、Windows管理者に課される。

POSIX ACLはUNIX管理者におもしろい難問を提供し、そのため、Windows ACL管理に適用 するために妥協を強いる。POSIX ACLは公式の標準としては適用されていない。という よりは、最終の標準は、draft standard 1003.1e revision 17である。これが、Samba が実装しているPOSIX文書である。

UNIXベンダは別々の流儀でPOSIX ACLを実装している。ACLをサポートしている数多くの Linuxファイルシステムがある。Sambaは数多くのPOSIX ACLの実装間のすべての違いを 透過的にする仕組みを提供する必要がある。SambaにおけるACLサポートのプレッシャー は、UNIXの世界でのACLサポートの標準化への圧力を顕著に増大する。

SambaはUNIXファイルシステムで実装されているPOSIX ACLが予想していない、 継承を実装しているWindows ACLという難問を取り扱う 複雑な事項を扱う必要がある。Sambaは通常のugoとACL機能を上書きすることが出来る masksのサポートを提供する。これは、WindowsのACLが 実装しなければならない方法を更に複雑にする。

#### UNIX POSIX ACLの概要

POSIX ACLを調べる際に、ファイルとディレクトリ両方に対して操作する方法を 考えておかなければならない。ファイルのACLは以下の意味を持つ:

    # file: testfile      <-- ファイル名# owner: jeremy       <-- ファイルの所有者# group: users        <-- POSIXグループの所有者user::rwx             <-- ファイルの所有者に対する許可 (user)user:tpot:r-x         <-- 追加のユーザに対する許可 `tpot'group::r--            <-- ファイルグループの所有者に対する許可 (group)group:engrs:r--       <-- 追加のグループに対する許可 `engineers'mask:rwx              <-- グループに対して'論理積'を取る時のマスク値other::---            <-- その他に対する許可 (other)

ディレクトリのACLは以下の意味を持つ:

    # file: testdir       <-- ディレクトリ名# owner: jeremy       <-- ディレクトリの所有者# group: jeremy       <-- POSIXグループの所有者user::rwx             <-- 所有者に対するディレクトリの許可 (user)group::rwx            <-- 周遊するグループに対するディレクトリの許可 (group)mask::rwx             <-- グループに対して'論理積'を取る時のマスク値other:r-x             <-- その他に対する許可 (other)default:user::rwx     <-- 継承された所有者に対する許可default:user:tpot:rwx <-- 継承されたあるユーザに対する許可 `tpot'default:group::r-x    <-- 継承されたグループに対する許可default:mask:rwx      <-- 継承された既定値のマスクdefault:other:---     <-- 継承されたその他に対するパーミッション (other)

#### Windowsのファイル ACLsからUNIX POSIX ACLへのマッピング

Microsoft Windows NT4/200XのACLはPOSIX ACLに当然マップされねばならない。 ファイルパーミッションのマッピングは、 WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法 で示されている。文字#は、Windows管理者がファイルに`フルコントロール` フラグをセットする時のみこのフラグがセットされる事を意味する。

Table 16.5. WindowsのファイルACLをUNIX POSIXファイルACLにマップする方法

WindowsのACE | ファイル属性フラグ
--- | ---
フルコントロール | #
フォルダのスキャン/ファイルの実行 | x
フォルダの一覧/データの読み取り | r
属性の読み取り | r
拡張属性の読み取り | r
ファイルの作成/データの書き込み | w
フォルダの作成/データの追加 | w
属性の書き込み | w
拡張属性の書き込み | w
サブフォルダとファイルの削除 | w
削除 | #
アクセス許可の読み取り | all
アクセス許可の変更 | #
所有権の取得 | #

マッピングテーブルを見てわかるように、1対1でマッピングされるものは1つもなく、 そのため、Sambaは、Windowsに、管理者によって意図されるおおよその方向に操作 させる、論理的なマッピングをしなければならない。

一般的に、UNIX POSIXのユーザ/グループ/その他のパーミッションのマッピングは Windows ACLにマップされる。これは、POSIX ACLの作成に優先する。POSIX ACLは ファイルかディレクトリを所有しているユーザとグループ以外のユーザとグループの ためのアクセス制御を行うために必要である。

UNIX管理者はUNIX環境下で任意のディレクトリパーミッションを設定出来る。 Windows管理者はファイルの所有者に対して読み取り許可を削除するために、Windows エクスプローラで行う事が出来ないというように、より制限されている。

#### WindowsのディレクトリACLs の UNIX POSIX ACLへのマッピング

UNIX POSIXのディレクトリパーミッションとUNIX POSIXのACLを、Windowsのディレクトリ ACLにマップされる、Windows ACEにマッピングする時に、おもしろいことが起きる (アクセスコントロールエントリ(ACE)はACLの個々の要素である)。

ファイルパーミッションの時に説明したのと全く同じように、ディレクトリ パーミッション機能するが、いくつか注意しなければならない例外と、 ディレクトリパーミッションを準備する時に、抜け目のない管理者が注意を払う2、3の 特色がある。

## よくあるエラー

ファイル、ディレクトリと共有アクセスの問題はメーリングリスト上での共通の話題である。以下は最近メーリングリストで話題になった例である。

### Publicな共有にユーザが書き込めない

以下の不満はSambaメーリングリスト上でしばしば聞かれる: “ ファイルとディレクトリのパーミッションに関していくつかの問題に直面している。 ドメインにadmin user(root)としてログイン出来、ファイルを作成/変更するための パーミッションを、誰でも持つ必要があるPublicな共有があるが、rootしかファイルを 変更できず、それ以外の人は出来ない。結局常時サーバの所に行って、 `chgrp -R users *`と`chown -R nobody *` を実行し、他のユーザに対してファイルに対して変更が出来るようにしなければならない。 ”

この問題を解決できる1つの方法がある:

1. 共有されているディレクトリの最上位に移動する。

2. 好みのpublicなユーザとグループに所有者を設定する

       $ find `directory_name' -type d -exec chown user:group {}\;$ find `directory_name' -type d -exec chmod 2775 {}\;$ find `directory_name' -type f -exec chmod 0775 {}\;$ find `directory_name' -type f -exec chown user:group {}\;

   ### Note

   上記はすべてのディレクトリに`SGID ビット`を 設定する。これが何をするかはUNIX/Linuxのマニュアルページを読む こと。これにより、ディレクトリ中に作成されるすべてのファイルと ディレクトリツリーは現在のユーザと、ディレクトリ作成時に所有する グループによって所有される。

3. ディレクトリが`/foodbar`だとする:

       $ chown jack:engr /foodbar

   ### Note

   これは以下と同じである:

       $ chown jack /foodbar$ chgrp engr /foodbar

4. 以下のようにタイプする:

       $ chmod 2775 /foodbar$ ls -al /foodbar/..

   以下が表示される:

       drwxrwsr-x  2 jack  engr    48 2003-02-04 09:55 foodbar

5. 以下のようにタイプする:

       $ su - jill$ cd /foodbar$ touch Afile$ ls -al

   `Afile`がJillによって作成されて、所有権を持っている ことを確認し、以下のようにJackが許可されていることを確認する: and permissions of Jack, as follows:

       -rw-r--r--  1 jill  engr     0 2007-01-18 19:41 Afile

6. もしも、ディレクトリに書き込みパーミッションを持たねばならないユーザが グループengrのメンバでないならば、`smb.conf`中の 共有のエントリを以下のようにする:

   `force group = engr`

### force userセットでrootとしてファイル操作が完了する

admin users中にユーザがある時、 force userが設定されていたとしても、 Sambaは常時このユーザに対してファイル操作をrootとして行う。

### SambaでMicrosoft Wordを使うとファイルの所有者が変更される

質問:“Aが所有者のword文書をBがセーブする。 更新したファイルは所有者がBになる。なぜSambaはこのようにするのか? どうやったら修復できる?”

答え:Wordは、Wordの文書を修正/変更した時に以下の 作業を行う:Microsoft Wordは一時的な名前で新しい文書を作成する。Wordは 次に古い文書をクローズしてそれを削除し、新しい文書をオリジナルの文書 の名前に改名する。Sambaが、新しい文書がオリジナルの文書の所有者によって 所有すべきであるということを知るための機構はない。SambaはMicrosoft Word によってファイルが改名されたことを知るすべはない。Sambaが告げることが 出来る限りのことは、作成されるファイルは新しいファイルであり、 アプリケーション(Word)が更新しているものではない、ということである。

パーミッション問題を解決するための回避方法がある。これは、`smb.conf` ファイル中からファイルシステムの動作を管理できる方法についての理解と、 同様に、UNIXファイルシステムの動作について理解することを深める。 Word文書を変更するディレクトリに`chmod g+s `directory_name'` を設定する。これは、生成されるすべてのファイルはディレクトリを所有している グループになるようにする。 `smb.conf`中の共有定義セクションを以下のように 設定する。

`force create mode = 0660`
`force directory mode = 0770`

これらの2つの設定は、共有中で作成される、すべてのディレクトリとファイルが ディレクトリそれ自身上に設定された所有者とグループによって読み書きができる ようにする。

Prev | Up | Next
Chapter 15. User Rights and Privileges | Home | Chapter 17. ファイルとレコードのロッキング