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

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

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

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

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

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

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

$ ls -la
total 632
drwxr-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 muchado02
drwxrwxrwx    2 maryo   gnomes       48 2003-05-12 22:29 muchado03
drw-rw-rw-    2 maryo   gnomes       48 2003-05-12 22:29 muchado04
d-w--w--w-    2 maryo   gnomes       48 2003-05-12 22:29 muchado05
dr--r--r--    2 maryo   gnomes       48 2003-05-12 22:29 muchado06
drwsrwsrwx    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になったフラグは"できない"と同値で、 “-”文字で表現される(“サンプルファイル”を参照)。

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

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

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

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

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

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

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

他の制御中に記載があるパラメーターはファイルアクセスへの 不注意によるバリアを作成する方向で、管理者によってしばしば使われる。それらは、 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.

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

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

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

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

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のフルコントロールとして表示される。

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

ファイルとディレクトリのパーミッションの変更はダイアログボックス中に表示された パーミッションの変更と同じくらい簡単で、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パラメーターとの相互作用を制御する4つのパラメーターがある:

ユーザーがパーミッションを適用するために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ファイル中の共有固有のセクションに、以下のパラメーターを記述する:

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

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

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が 実装しなければならない方法を更に複雑にする。

# 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)

# 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)

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

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

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

質問:“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中の共有定義セクションを以下のように 設定する。

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