Linux の 302 (Mixed Environment) 試験対策: 認証と承認

認証メカニズム、そしてアクセス制御の構成

システム管理者のための、LPIC (Linux Professional Institute Certification) の LPI-302 試験に備えるために、パスワードをセットアップして保存する方法、Samba と LDAP を統合する方法、そして ACL を使用して Linux インストール済み環境を保護する方法を学んでください。

Sean A. Walberg, Senior Network Engineer

Photo of Sean WalbergSean Walberg はネットワーク・エンジニアであり、ネットワークについて 2 冊の本も書いています。これまで医療やメディアをはじめ、さまざまな業界に携わってきました。



2011年 11月 11日

この連載について

この連載は Linux システム管理タスクの学習に役立つだけでなく、LPIC-3 (Linux Professional Institute Certification レベル 3) 試験に備えるための教材にもなります。

連載の各記事についての説明とリンクについては、developerWorks の LPIC-3 ロードマップを参照してください。現在進行中のこのロードマップは、LPIC-3 試験の最新の目標 (2010年 11月) を反映しています。完成した記事はその都度ロードマップに追加されていきます。

この記事では、以下の概念について学びます。

  • ローカル・パスワード・データベースのセットアップ
  • smbpasswd ファイル・フォーマット
  • Samba と他のシステムとの間でのパスワードの同期
  • パスワードの代替バックエンド・ストレージ
  • Samba とLDAP (Lightweight Directory Access Protocol) の統合
  • アクセス制御リスト (ACL)

この記事は、LPI (Linux Professional Institute) のMixed Environment Specialty 試験 (302) の主題 313 の目標 313.2 の試験対策となります。この目標の重要度は 8 です。

この記事は、LPIC-3 Specialty「302 Mixed Environment Exam」試験の主題 313 の目標 313.2 の試験対策となります。この目標の重要度は 8 です。

前提条件

この連載記事を最大限に活用するには、Linux の高度な知識と、記事に記載されたコマンドを演習できる実際の Linux システムが必要です。さらに、認証および承認メカニズムのテストに使用できる Windows 環境を利用できることも条件となります。


Samba の認証メカニズム

選択的な LPI-302 試験について

LPIC (Linux Professional Institute Certification) には、さまざまなレベルがあり、レベルが上がるにつれ、より深い知識と経験が必要になってくるという点で、他の多くの認定と似ています。LPI-302 試験は、LPIC レベル階層のレベル 3 に位置する選択的な Specialty 認定試験であり、Linux システム管理に関する高度な知識が求められます。

LPIC レベル 3 (LPIC-3) 認定を取得するには、2 つのレベル 1 試験 (101 と 102)、2 つのレベル 2 試験 (201 と 202)、そして LPIC-3 Core Exam (301) に合格しなければなりません。これらの試験に合格した後、LPI-302 などの選択的な Specialty 認定試験を受けることができます。

Samba では、さまざまな方法でパスワードおよびアカウント情報をパスワード・バックエンドに保存することができます。これらの方法には、ローカル・ディスク・ストレージを使用する方法もあれば、ネットワークをベースとした方法もあります。さらに、Samba には Linux サーバーが Samba 認証システムを使用してログインするためのメカニズムもあります。

20 年近くの歴史がある Samba では、さまざまな技術が使われてきました。古い認証システムは今でもサポートされていますが、その古い技術は新しい技術に取って代わられています。けれども、Samba のドキュメントを読むと、それらの古い認証システムについて以前と変わらずに説明している箇所を今でも目にします。この混乱をさらに増しているのは、特定の技術と同じような名前が付けられたコマンドライン・ツールです。

パスワード・バックエンドという名前にもかかわらず、このバックエンドにはパスワードだけでなく、アカウント・データやその他の属性も保存されます。データ自体は LDAP サーバーに保存されることもあります。その場合、Samba のパスワード・バックエンドが Samba と LDAP との仲介をすることになります。

さらに興味深いことに、Microsoft デバイスでは、パスワードのハッシュ化に、UNIX のパスワード・フォーマットとは異なるフォーマットを使用することになっています。パスワードがハッシュ化されるということは、一方向の暗号化が行われるということなので、UNIX のパスワード・フォーマットから Samba のパスワード・フォーマットへの変換、あるいはその逆の変換は不可能です。したがって、Samba クライアントを UNIX パスワード・データベースのデータを使用して認証することはできません。

ローカル・パスワード・データベースによる方法

皆さん独自のフィードを作成してください

新しい記事が追加された際、あるいは内容が更新された際に通知を受けられるように、RSS、Atom、または HTML によるカスタム・フィードを作成することができます。それには、developerWorks RSS フィードにアクセスしてください。対象のゾーンとしては「Linux」を選択し、情報の種類としては「記事」を選択して、キーワードには「Linux Professional Institute」と入力します。そして最後にフィードの種類を選択します。

ローカル・パスワード・データベースはネットワークを介して認証を行うのではなく、サーバーに関する情報が保存されたパスワード・バックエンドを参照します。こうした方法は最もパフォーマンスに優れているわけではありませんが、使用するのは簡単です。

平文のバックエンドについて言及した資料を目にすることもあります。かつては、Windows クライアントのクレデンシャルは暗号化されていないフォーマットでサーバーに渡されていましたが、その後、パスワードを UNIX スタイルにハッシュ化し、その結果をローカル・パスワード・データベースと照合することが可能になりました。今では、レジストリーを変更しない限り、Windows クライアントが平文のバックエンドを使用することはありません。暗号化されていないパスワードをネットワークで渡すことを避けられるのであれば、それに越したことはありません。したがって、平文のパスワード・データベースについて書かれていても、実際にそれが使用されている場面に遭遇することはないでしょう。

古いシステムのほとんどは、smbpasswd パスワード・バックエンドを使用します。このバックエンドは単純なフラット・ファイルにアカウント・データを格納します。フラット・ファイル内のデータは、アカウント名、パスワード・ハッシュ、そして基本的なアカウント情報からなります。この基本アカウント情報は単純なもので、Microsoft 管理ツールで使用するような詳細な属性は保存されません。

現在好んで使われているローカル・ストレージ・バックエンドは tdbsam です。主題 310 の目標 310.3 に関する記事で取り上げた簡易データベース (TDB) ファイルを思い出してください (「参考文献」にリンクを記載)。TDB ファイルは、key-value 型の情報に素早くアクセスできる恒久的な手段となります。tdbsam バックエンドが情報を格納するフォーマットは、Microsoft Windows NT の SAM (Security Account Manager) とよく似ており、SAM に保存できるものであれば、そのほとんどを Samba サーバーですることが表現できます。このことから、tdbsam は Microsoft システムとのハイレベルな互換性を提供します。

tdbsam の欠点は、これがバイナリー・フォーマットであることです。そのため、ファイルの内容を調べるのは容易ではありません。「Linux の 302 (Mixed Environments) 試験対策: 簡易データベース (TDB) ファイル」(developerWorks、2011年 3月) では、ファイルからキーと値のペアを取得する方法を紹介しましたが、この情報を意味のあるものに再構成するのはユーザーの仕事です。認証情報を格納するファイルは、passdb.tdb と呼ばれます。

smbpasswd データベースを使用する

新しく Samba をインストールするときに、バックエンドとして smbpasswd データベースを選択することはないでしょう。けれども、現場でこのバックエンドに遭遇する可能性はあるため、smbpasswd データベースについて理解しておくことは重要です。

パスワード・データベース・バックエンドを構成するには、passdb backend パラメーターを使用します。以下のコードでは、smbpasswd データベースを選択しています。

[global]
  passdb backend=smbpasswd:/etc/samba/smbpasswd

上記のコードで使用されている passdb backend というグローバル・パラメーターには、smbpasswd の後をコロン (:) で区切り、passwd ファイルへのパスを続けた値が指定されています。コロンとパスはオプションですが、使用することをお勧めします。この指定を省略すると、Samba が自動的に選択したディレクトリーにファイルを配置します。Samba は再起動時にこのファイルを作成しますが、その時点でのファイルの中身は空です。

ユーザーを追加するには、smbpasswd コマンドを使用します。リスト 1 に、ユーザーを追加すると smbpasswd ファイルの内容はどのようになるかを示します。

リスト 1. smbpasswd ファイルへのユーザーの追加
# smbpasswd -a sean
New SMB password:
Retype new SMB password:
Added user sean.
# cat smbpasswd
sean:1001:01FC5A6BE7BC6929AAD3B435B51404EE: \
0CB6948805F797BF2A82807973B89537:[U          ]:LCT-4DCDE4D8:

リスト 1 では最初に -a フラグを使用して sean というユーザーを追加しています。追加するユーザーはローカル UNIX データベースに存在するユーザーでなければなりません。そうでないと、コマンドの実行は失敗します。ユーザーを追加すると、smbpasswd ファイルにはそのユーザーに関する行が 1 行追加されます (リスト 1 では読みやすいように改行されています)。この行は、コロンで区切られたフィールドからなります。これらのフィールドは、以下を指定するものです (記載順にリスト)。

  • ユーザー名
  • UNIX のユーザー ID
  • 従来型の Lanman ハッシュ (このハッシュにはセキュリティーが講じられていないため、実質的には平文のパスワードです。)
  • セキュアな Windows NT ハッシュ (最近のクライアントを認証するには、このハッシュが必要です。)
  • アカウント・フラグ (上記で使用されているフラグは唯一、ユーザー・アカウントを意味する U だけです。その他のフラグについては、smbpasswd(5) の man ページを参照してください。)
  • アカウントの最終変更時刻 (LCT) (UNIX 時間のタイム・スタンプを 16 進の値で表したものです。)

ユーザーが自分のパスワードを変更するには smbpasswd を実行します。root ユーザーであれば、ユーザー名を指定して別のユーザーのパスワードを変更することができます。-a フラグが必要なのは、アカウントを追加する場合のみです。

平文のファイルには、ファイルの内容を直ちに調べられてしまうという点、そしてアカウントに関して保存できるメタデータが少ないという点が欠点としてあります。そこで作成されたのが、tdbsam データベースです。

tdbsam データベースを使用する

tdbsam データベースは、smbpasswd データベースの代わりとなる手段として設計されました。tdbsam データベースを使用することで、アカウントに関して保存できるデータが増えるだけでなく、通常のデータベースを使用するため、速度の点でも大幅に改善されます。

tdbsam データベースが持つ制限に関するガイドラインは固まっていません。公式のドキュメントでは、250 ユーザーを目安に LDAP データベースへのアップグレードを推奨していますが、他の資料では、数千のクライアントをサポートできるという事例証拠を挙げています。これらの数に大きく影響を及ぼす要素としては、同時リクエスト数が挙げられるようですが、同時リクエスト数は、クライアントの数、ワークロード、そしてクライアントとサーバーとの間のレイテンシーに左右されます。ほとんどのアプリケーションと同じく、ネットワークの限界を予測するには、レイテンシー、CPU、ディスク I/O といった重要な要素をモニターするべきです。

tdbsam バックエンドを構成するのは、smbpasswd の場合と同じく簡単で、passdb backend=tdbsam (オプションでファイル名を指定することもできます) を global セクションに追加して、Samba を再起動するだけの話です。認証情報を格納する TDB ファイルのデフォルト名は、passdb.tdb です。

smbpasswd ツールは、tdbsam データベース内のユーザーを操作する場合にも使用することができます。リスト 2 に示すのは、smbpasswd でユーザーを作成する前と作成した後の tdbsam データベースの内容です。

リスト 2. smbpasswd を使用してユーザーを作成し、tdbsam の内容を表示する
# tdbdump passdb.tdb
{
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"
}
# smbpasswd -a sean
New SMB password:
Retype new SMB password:
Added user sean.
# tdbdump passdb.tdb
{
key(13) = "RID_00000bba\00"
data(5) = "sean\00"
}
{
key(10) = "USER_sean\00"
data(205) = "\00\00\00\00....EC\04\00\00"
}
{
key(13) = "INFO/version\00"
data(4) = "\03\00\00\00"
}

passdb.tdb の最初の内容は、バージョン・ストリングが含まれる 1 つのキーがあるだけです。この状態で、とまったく同じ方法でユーザーを追加します。smbpasswd ユーティリティーは、smb.conf を読み取って、ユーザーをどのように追加するべきかを理解するだけの賢さを持ち併せています。ユーザーが作成されると、パスワード・データベースには 2 つのキーが追加されます。最初のキーは Microsoft の相対 ID (RID) をユーザー名にマッピングし、次のキーはユーザーに関する情報を格納します。tdbsam のデータは、ほとんどがバイナリーなので、デコードするには Samba ソース・コードでデータ構造のレイアウトを調べる必要があります。


LDAP 認証

比較的優れたパフォーマンスを発揮する TDB ファイル・フォーマットは、大抵の小規模な環境に適していますが、TDB ファイルに適した規模を超えてスケーリングするには、LDAP サーバーに対して認証を行う必要があります。LDAP はツリーのような構造を持つことから、認証を行うには適しています。Microsoft の Active Directory ドメイン・サービスも、LDAP を中心に構築されています。

LDAP サーバーをセットアップする

Samba と LDAP を統合するための最初のステップは、LDAP サーバーの構成です。詳しい説明はこの記事ではしませんが、301 試験のための学習用チュートリアルで、LDAP について詳しく取り上げています (「参考文献」を参照)。Samba と LDAP を統合するには LDAP についての知識が必要になるため、上記チュートリアルで改めて LDAP について確認することをお勧めします。

Linux サーバーで最もよく使用されている LDAP サーバーは、OpenLDAP です。リスト 3 に、Samba と統合できる状態の OpenLDAP 構成ファイル、slapd.conf を記載します。

リスト 3. slapd.conf
# Include the core schema files, and the perquisites for samba.schema
include	           /etc/openldap/schema/core.schema
include            /etc/openldap/schema/cosine.schema
include            /etc/openldap/schema/inetorgperson.schema
include            /etc/openldap/schema/nis.schema
include            /etc/openldap/schema/samba.schema

database bdb
# Configure the tree and the admin user
pidfile /var/run/openldap/slapd.pid
suffix "dc=ertw, dc=com"
rootdn "cn=admin, dc=ertw, dc=com"
rootpw linux
directory /var/lib/ldap

# Indexes
index objectclass             eq
index cn                      pres,sub,eq
index sn                      pres,sub,eq
# For storing Unix accounts in LDAP
index uidNumber               eq
index gidNumber               eq
index memberUid               eq
# Samba specific
index uid                     pres,sub,eq
index displayName             pres,sub,eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq

index default               sub

リスト 3 では、すべてのオブジェクトに対して dc=ertw, dc=com という接頭辞を使用しています。最初のセクションは、Samba との統合に必要なすべてのスキーマ要素をロードします。core.schema は OpenLDAP の基本操作に必要なスキーマで、samba.schema は Samba の objectClass を取り込むスキーマです。他のスキーマは samba.schema の前提条件であるため、このスキーマよりも前でインクルードする必要があります (これらのファイルのインクルードは、記載されている順に行われるためです)。

database bdb で始まる次のセクションは、Berkeley データベースを使用することを指定し、管理ユーザーとディレクトリーを含め、LDAP ツリーに関する情報を提供します。ファイルの残りの部分は、ツリーの検索を容易にするために索引をセットアップしています。これらの索引は、OpenLDAP のデフォルト構成と Samba 資料から引用されているものです。

次はこの LDAP ツリーに、ユーザー、コンピューター、グループを保存する各種のコンテナーを取り込む必要があります。また、サーバーのセキュリティー ID (SID) をいくつかのレコードに関連付けなければなりません。これは複雑な作業ですが、幸い、この作業を簡易化する smbldap-tools というプロジェクトがあります。お使いのディストリビューションには、このプロジェクトのパッケージが付属していると思いますが、そうでない場合には手動でダウンロードしてインストールしてください (「参考文献」のリンクを参照)。

smbldap-tools ユーティリティーをインストールしたら、構成ファイルをくまなく調べて、ドメインまたはワークグループの名前や LDAP サーバーに接続するための管理情報など、必要な情報を入力します。その上で smbldap-populate コマンドを実行すると、ツリーが作成されます。リスト 4 に、このコマンドの出力を記載します。

リスト 4. LDAP ツリーへのデータの取り込み
# smbldap-populate
Populating LDAP directory for domain BOB (S-1-5-21-2287037134-1443008385-640796334)
(using builtin directory structure)

entry dc=ertw,dc=com already exist.
adding new entry: ou=People,dc=ertw,dc=com
adding new entry: ou=Groups,dc=ertw,dc=com
adding new entry: ou=Computers,dc=ertw,dc=com
adding new entry: ou=Idmap,dc=ertw,dc=com
adding new entry: uid=root,ou=People,dc=ertw,dc=com
...
adding new entry: cn=Replicators,ou=Groups,dc=ertw,dc=com
adding new entry: sambaDomainName=BOB,dc=ertw,dc=com

Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password:
Retype new password:

リスト 4 には、smbldap-populate コマンドがローカル・マシンの SID とドメインを判別して LDAP にディレクトリー構造を作成するプロセスが示されています。このツールは最後に root パスワードの入力を求めます。入力されたパスワードは、LDAP ツリー内で同期が取られます。

Samba を LDAP に接続する

LDAP を使用するように Samba を構成するには、サーバーに LDAP ツリーへのバインド方法を指示する必要があります。リスト 5 に、LDAP 認証に最小限必要な Samba の構成を記載します。

リスト 5. Samba を LDAP で認証するための最小構成
[global]
  passdb backend = ldapsam:ldap://ldap.ertw.com
  ldap suffix = dc=ertw,dc=com
  ldap user suffix = ou=People
  ldap group suffix = ou=Groups
  ldap admin dn = uid=samba_service,ou=People,dc=ertw,dc=com

リスト 5 はグローバル・スコープでの動作の構成であり、ローカル・サーバーが ldap.ertw.com に位置する LDAP サーバーをパスワード・データベース・バックエンドとして指すようにしています。最初に定義されている 3 つの接尾辞は、Samba に対してツリーの基本名、ユーザーのブランチ名、グループのブランチ名をそれぞれ通知するためのものです。リストの最後では、管理ユーザーの DN (Distinguished Name: 識別名) を構成します。このユーザーがツリーに接続するために使用されて、他のユーザーが認証されることになります。リスト 6 に、このユーザーの LDIF (LDAP Data Interchange) 情報を記載します。

リスト 6. 管理ユーザーのの LDIF
dn: uid=samba_service,ou=People,dc=ertw,dc=com
uid: samba_service
objectclass: person
objectclass: uidobject
description: Service account to allow Samba to authenticate
cn: samba_service
sn: samba_service
userPassword: {SSHA}tQNdW/bNxQGz2iGoLz5zFL5wJ8px43v5

管理者の DN に対してパスワードを設定するには、smbpasswd -w コマンドの後にパスワードを続けて入力します。これと同じパスワードに対して slappasswd コマンドによって生成したハッシュが、リスト 6 に示されている userPassword のハッシュです。これで、LDAP を使用するための準備は完了したので、Samba を再起動してください。

ユーザーを管理する

通常は、ドメイン SID を考慮しながら UNIX のユーザー ID と Microsoft SID との間のマッピングを管理しなければなりませんが、この管理作業ではエラーが起こりがちです。そこで役立つのが、smbldap-useradd コマンドです。例えば、sean というユーザーを追加するには、smbldap-useradd -a sean を実行します。-a パラメーターを指定することで、Samba の objectClass が LDAP オブジェクトに追加されます。これにより、ユーザー sean は Microsoft ドメインにログインできるようになります。そして最後に、smbldap-passwd コマンドに続けてユーザー名を指定して実行することで、指定したユーザーのパスワードを設定します。

これで、Samba サーバーに接続して、LDAP ツリーに提供したクレデンシャルを使用できるようになるはずです。smbldap-tools パッケージに含まれるその他多くのツールも、ユーザーの管理、そして大規模なマイグレーションの計画を行う上で役に立ちます。


Samba での UNIX 認証

シングル・サインオン、つまり Linux と Microsoft との間でパスワードを同期するのは簡単なことではありません。それは、この 2 つのオペレーティング・システムは、それぞれに異なる方法でパスワードを保存するためです。smbldap-tools パッケージは両方のシステムに同時に作用してこの問題を解決しますが、これ以外にも、パスワードの管理を Microsoft ネットワークに任せるという方法があります。

Linux では、PAM (Pluggable Authentication Module) と呼ばれる概念をサポートしています。PAM を使用すると、アプリケーションについての知識を持たない管理者でも、構成ファイルを操作することによって、サービスの認証方法を構成したり、認証プロセスを変更したりすることができるようになります。アプリケーションがユーザーを認証するために PAM ライブラリーを呼び出すと、PAM はその特定のサービスに対するユーザーからの認証要求を受け入れるかどうかを判断するために構成ファイルを調べ、認証の成功または失敗の結果をアプリケーションに返します。

これまで、ローカル・パスワード・ファイル、LDAP、Kerberos、さらには Microsoft ネットワークといった他のサービスに対して認証を行えるようにするための認証モジュールが数多く作成されてきました。こうしたサービスは pam_smb というモジュールによって提供されています。

pam_smb を構成する

お使いのディストリビューションには最新バージョンの pam_smb が付属しているはずですが、そうでない場合には、Web サイトからソース・コードをダウンロードすることができます (「参考文献」のリンクを参照)。構成するのは /etc/pam_smb.conf 内のモジュールです。ファイル・フォーマットは至って単純で、ドメインの名前の後に、認証に対応できる 1 つまたは 2 つのサーバーを続けるだけです。以下に、構成の一例を記載します。

MYGROUP
ALICE
BOB

上記の例は、MYGROUP ドメインまたはワークグループ内のユーザーを ALICE サーバーと BOB サーバーに照らし合わせて認証します。認証を処理するサーバーが 1 つだけしかない場合には、構成ファイルには、ドメインの行と認証サーバーの行の 2 行だけが含まれることになります。

次に必要な作業は、pam_smb を認証スタックに挿入することです。/etc/pam.d には、個々のサービスに固有の認証順序を参照するための構成ファイルがいくつか格納されています。これらのファイルでは、多くのファイルで共通する構成内容を直接記述する代わりに、共通ファイルをインクルードするのが通常であるため、ファイルの内容は似ているように見えます。試しに include キーワードでインクルードされているファイルを探してみてください。例えば Fedora では、共通ファイルに該当するのは password-auth または system-auth のいずれかです。リスト 7 に、password-auth ファイルの認証セクションを抜粋します。

リスト 7. password-auth の認証セクション
auth        required      pam_env.so
# Use samba authentication
auth        sufficient    pam_smb_auth.so debug
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

リスト 7 の各行は順に処理されます。先頭の行では、環境変数を設定する pam_env を呼び出しています。2 行目は、pam_smb が認証要求で追加のデバッグを行えるようにします。認証に成功した場合は、チェックだけで十分であると判断してユーザーをログインさせる一方、認証に失敗した場合には、pam_unix に制御が渡され、UNIX パスワード・ファイルとの照合が行われます。

PAM の操作を試してみるときには、root アカウントをログインしたままにして、有効であることが確実なファイルは閉じておくことが賢明です。システムからロックアウトされたとしても、誤ったファイルに正しいファイルを上書きすることで、簡単にアクセスを取り戻せます。

ネーム・サービス

Linux には、システム・ライブラリーがユーザー ID とグループ ID をそれぞれが表す名前にマッピングする方法を制御する、/etc/nsswitch.conf という名前のファイルがあります。このファイルは、NSS (Name Service Switch) システムを構成します。大抵のシステムが指すのはローカル・ファイル (/etc/passwd や /etc/group)、あるいは LDAP サーバー、NIS (Network Information Service) サーバーなどですが、Winbind というサービスを使用して、システム・ライブラリーに Microsoft ネットワークからマッピングを要求させることもできます。

この話題については、連載の次回の記事で詳しく取り上げます。今のところは、ユーザーは PAM によって認証される一方、ユーザー名とグループ名は NSS システムから認証されるということを理解しておけば十分です。


アクセス制御リスト

Microsoft の OS がインストールされているサーバーは、かなり強固なパーミッション一式をサポートすることから、管理者は極めて詳細にファイルやディレクトリーへのアクセスを構成することができます。一方で、一部の UNIX システムにはファイルシステム ACL が提供されているものの、そのサポートは広まっていないため、Linux システムでは Everyone/Group/User アクセスに対し、従来の読み取り/書き込み/実行ビットしか使用できないことは少なくありません。このことから、Samba では Microsoft クライアントに対する ACL インターフェースを提示して、このインターフェースを UNIX ファイルのパーミッションにマッピングし、オプションで情報を TDB ファイルに保存する必要があります。

UNIX と Windows NT の間でファイルのパーミッションをマッピングする方法を制御するパラメーターはいくつかありますが、そのうち重要なのは、force security modesecurity mask です。同時に機能するこの 2 つのパラメーターは、ファイルのパーミッション・ビットをそれぞれセット、リセットします。

ファイルのパーミッションについて復習する

UNIX でのファイルのパーミッションを示すモードは 8 進数で表され、実行許可の値は 1、書き込み許可の値は 2、読み取り許可の値は 4 です。これらの数値は、8 進数を構成するために必要な 3 つのビットに対応します。3 桁の 8 進数のうち、最初の桁はファイルの所有者のパーミッション、2 番目の桁はファイルの所有グループのパーミッション、そして最後の桁はその他のユーザーのパーミッションです。したがって、モードが 750 のファイルの場合、所有者には読み取り/書き込み/実行が許可され、所有グループには読み取り/実行が許可されますが、その他のユーザーはこのファイルにアクセスできないことになります。

パーミッションを設定したり、設定の解除をしたりするには、8 進数でのバイナリー演算を実行することができます。OR 演算子は該当するビットをセットする一方、AND 演算子はビットをクリアします。例えば、1 OR 4 は 5 になります。これは、初めに 1 を表すビットをセットした後、4 を表すビットをセットするためです。同様に、5 OR 4 も同じく 5 になります。5 は 1 を表すビットと 4 を表すビットをともにセットした組み合わせであり、すでにセットされているビットをセットしても、効果はないからです。

ANDOR とは対照的な演算子です。セットされているビットの位置を最終結果まで維持するには、そのビットを AND 演算子の両側でセットする必要があります。1 AND 1 は、演算子両側で 1 を表すビットがセットされるため、1 になります。5 AND 1 は 1 になります。1 を表すビットは両側でセットされますが、4 を表すビットは演算子の左側でしかセットされないためです。ANDOR を慎重に使用することによって、ビットが常にセットまたはクリアされた状態にすることができます。

ビット操作を Samba に適用する

force security mode は、ファイルの作成時、またはクライアントがファイルのパーミッションを変更しようとしたときに、強制的にパーミッションのビットをセットします。デフォルトではビットは 000 に設定されます。これは、強制的にセットされるビットはないことを意味します。force security mode を例えば 700 に設定にすると、ファイルの所有者には常に読み取り/書き込み/実行が許可されるように強制されます。そのため、ユーザーがパーミッションを変更して自分のファイルの読み取りを禁止しようとしても、常に読み取りができる状態になります。

同様に、security maskAND 演算を実行してビットをクリアします。デフォルトでは、このモードは 777 であるため、何もクリアされていません。このファイルのモードを 775 にすると、その他のユーザーからの書き込み許可のビットがクリアされるため、ユーザーは任意のユーザーが書き込みを行えるファイルを作成できなくなります。

security maskforce security mode は、全体に適用することも、共有レベルで適用することもできます。この 2 つのパラメーターは、公開フォルダーとグループ・フォルダーでユーザーが介入しなくても、ファイルに対して所有グループのパーミッション、またはその他のユーザーのパーミッションが適切に設定されるようにする場合に、とりわけ役に立ちます。

参考文献

学ぶために

製品や技術を入手するために

  • smbldap-tools パッケージは、Samba と LDAP の統合を大幅に簡易化します。
  • pam_smb を使用すると、Microsoft クレデンシャルを使って Linux サーバーにログインできます。
  • Samba の最新バージョンを入手して、最新機能を追加してください。
  • 複数の環境のデータにアクセスするには、IBM Tivoli Directory Integrator の試用版を検討してください。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=772492
ArticleTitle=Linux の 302 (Mixed Environment) 試験対策: 認証と承認
publish-date=11112011