PASSWD(5)

名称
passwd - パスワードファイルのフォーマット

解説
passwd ファイルは改行で区切られたレコードから成ります。 ユーザごとに 1 レコードが対応し、 コロン(``:'')で区切られた 10 個の欄が含まれます。 これらの欄は以下の通りです:

name
    ユーザのログイン名。

password
    ユーザの 暗号化された パスワード。

uid ユーザのid。

gid ユーザのログイングループid。

class
    ユーザのログインクラス。

change
    パスワードの変更時間。

expire
    アカウントの有効期限。

gecos
    ユーザについての一般的な情報。

home_dir
    ユーザのホームディレクトリ。

shell
    ユーザのログインシェル。

最初の空白文字でない文字がポンド記号(#)であるような行は注釈であり、無視 されます。スペース、タブ、改行だけからなる空行もまた無視されます。

name 欄はコンピュータアカウントにアクセスするのに用いられるログインであり、 uid 欄はそれに結び付けられた数字です。これらはファイルアクセスを制御するので、 両方共そのシステム(またしばしば複数のシステムにわたる1つのグループ)の中 で一意であるべきです。

同じログイン名や同じユーザidのエントリを複数持つことは可能で すが、普通それは誤りです。これらのファイルを取り扱うルーチンはしばしばそ の複数エントリの 1 つだけを返しますし、 そしてそれはランダムな選択によるものです。

ログイン名は決してハイフン(``-'')で始めてはいけません。また、メーラを 混乱させる傾向にあるので、大文字やドット(``.'')も絶対に名前の一部にしな いことを強く推奨します。コロン(``:'')は歴史的にユーザデータベース中の欄 を分けるために用いられてきたので、いかなる欄にも含まれません。

password欄はパスワードの 暗号化された 形です。 password 欄が空ならば、そのマシンへアクセスするのに何のパスワードも必要としないで しょう。これはほとんど恒常的に誤りです。これらのファイルは暗号化された ユーザパスワードを含んでいるので、 適当な権利無しにはいかなる人によっても可読であっ てはいけません。管理上のアカウントは1個のアスタリスク ‘*’ を含むパスワード欄を有しており、これは通常のログインを許しません。

group欄はユーザがログインした上で位置付けられるグループです。このシステムは マルチグループ( groups(1) 参照) をサポートしますが、この欄はユーザの1次グループを指名します。2次グループの メンバは /etc/group の中で選ばれます。

class 欄はユーザのログインクラスに対するキーです。ログインクラスは login.conf(5) の中で定義されます。 login.conf(5) は、ユーザの属性、アカウンティング、リソース、環境設定に関する termcap(5) 形式のデータベースです。

change 欄は GMT における基準時点からの秒数を表したものであり、 この時までにアカウントに対するパスワードを変更する必要があります。 パスワードエージング機能をなくすには、 この欄を空欄にしておくか0をセットしておけば良いです。

expire 欄は GMT における基準時点からの秒数を表したものであり、 その時にアカウントが消滅します。 アカウント再設定機能をなくすには、 この欄を空にセットしておくか0をセットしておけば良いです。

gecos 欄はコンマ(``,'')で区切られた以下のような副欄を通常含んでいます:

    fullname		ユーザのフルネーム
    office		ユーザの職場の位置
    wphone		ユーザの職場の電話番号
    hphone		ユーザの自宅の電話番号

この情報は フィンガープログラム finger(1) によって利用され、最初の欄はシステムのメーラ によって使われます。fullname 欄内にアンパサンド文字 ‘&’ が現われると、この欄を使うプログラムはそれをそのアカウントのログイン名の 大文字版に置き換えます。

ユーザのホームディレクトリは、ユーザがログインして位置付けられる完全な UNIX パス名です。

shell欄はユーザの好むインタプリタです。 shell 欄になにも無ければ Bourne シェル (/bin/sh) が仮定されます。セキュリティ上の理由により、シェルがシステムへのアクセス を許さないスクリプト(例えば nologin(8) スクリプト)に設定されている場合、いかなる環境変数も渡されないように配慮さ れるべきです。 sh(1) については、これは -p フラグを指定することで可能です。これが他のシェルでどのように行なわれるか は、特定のシェルの文書を調べてください。

YP/NIS との相互作用

  NISパスワードデータへのアクセスを可能にする
システム管理者は /etc/master.passwd ファイルに特別なレコードを付け加えることによって、パスワード情報について NIS/YPを用いるように FreeBSD を設定できます。ハッシュされたパスワードデータベースおよび /etc/passwd ファイル( /etc/passwd は絶対に手動で編集してはいけません)に変更が適切にマージされるように、 エントリは vipw(8) で付加するべきです。別の方法としては、なんらかの方法で /etc/master.passwd を修正した後、 pwd_mkdb(8) を用いてパスワードデータベースを手動で更新することができます。

NISを活性化するための最も簡単な方法は、名前欄にプラス符号(`+')だけを持つ、 以下のような空のレコードを付け加えることです。

    +:::::::::

`+' は、 FreeBSD の標準Cライブラリの getpwent(3) ルーチンに対し、 検索において NIS パスワードマップを使用開始するよう指示します。

上記のエントリは ワイルドカード エントリとして知られていることに注意してください。なぜなら、それは全ての ユーザと一致し (他に情報を持たない `+' は、全員に一致します)、 全 NIS パスワードデータを無変更にて引き出すことを許します。 一方、 NIS エントリで `+' の次にユーザ名やネットグループ名を指定することによって、 どのようなデータが NIS パスワードマップから展開されるのか、 およびそれがどのように解釈されるのかについて、 管理者が影響を与えることができます。 この特徴を示す、少数のレコード例を挙げます(1 つの master.passwd ファイル中には複数の NIS エントリを持つことが可能であることに注意):

    -mitnick:::::::::
    +@staff:::::::::
    +@permitted-users:::::::::
    +dennis:::::::::
    +ken:::::::::/bin/csh
    +@rejected-users::32767:32767::::::/bin/false

特定のユーザ名は明示的にリストされますが、ネットグループは `@' を前に付け て表されます。 上の例では、``staff'' および ``permitted-users'' ネットグループ のユーザは、NIS から読まれ無変更で使用されるパスワード情報を持ちます。 言い換えれば、それらのユーザはそのマシンに通常のアクセスを許される ということです。ユーザ ``ken'' および ``dennis'' は、 ネットグループを通じてではなく明示的に名前が指定されており、 NIS から読まれるパスワード情報を持ちます。 例外は、ユーザ ``ken'' のシェルが /bin/csh に再マップされることです。 これは、NISパスワードマップで指定されたシェルの値が、ローカル master.passwd ファイルの特別なNISエントリで指定された値によって上書きされることを意味します。 ユーザ ``ken'' は csh シェルを割り当てておいても良いかも知れません。 なぜなら、 政治的あるいは技術的な理由でクライアントマシンにインストールされていない 別のシェルを、彼の NIS パスワードエントリに指定されているかもしれないためです。 他方、``rejected-users''ネットグループのユーザは、そのUID、 GID、シェルが不正な値で上書きされているのでログインできなくなります。

ユーザ ``mitnick'' は、そのエントリが `+' ではなく `-' で指定されているので、 完全に無視されることになります。 マイナスエントリは、 ある NIS エントリを完全に遮断するために用いることができます。 このような方法でパスワードデータが除外されたユーザは、 システムから全く認識されません。(マイナスエントリで指定された 上書き情報は無視されます。 なぜなら、システムが最初に認識しないことにしたユーザの上書き情報を処理 することは無駄だからです。) 一般にマイナスエントリは、 ある権限のあるネットグループのメンバとなってアクセスを許されるかもしれない ユーザを特別に除外するために使用します。 例えば ``mitnick'' が ``permitted-users'' ネットグループのメンバであり、 いかなる理由があってもそのネットグループ内に留まることを許す必要がある場合 (おそらくそのドメイン内の他のマシンにアクセスすることを保証するため)、 管理者はマイナスエントリを使用することにより、 特定のシステムへのアクセスを拒否し続けるこ とができます。また、アクセスを許されたユーザおよびその残りを削除したよう なよくありそうな混み入ったユーザのリストを生成するよりは、むしろアクセスを 許されないユーザを明示的にリストする方が容易なことが多いです。

プラスおよびマイナスエントリは、先行一致優先で最初から最後の順で評価されま す。これはシステムが特定のユーザに一致する最初のエントリだけを使用するこ とを意味します。例えば、``staff'' ネットグループと ``rejected-users'' ネットグループの両方のメンバとなっているようなユーザ ``foo'' は、 上の例では ``rejected-users'' のエントリの前に ``staff'' のエントリがありますので、 システムに許可されます。もし順序が逆なら、今度はユーザ ``foo'' は ``rejected-users'' として認識され、アクセスは拒否されます。

最後に、 /etc/master.passwd ファイルの NIS アクセスエントリで指定されたユーザまたはネットグループ のどれとも一致しないNISパスワードデータベースレコードは、(マイナスエントリ を使って指定した全てのユーザと共に)全て無視されます。先に示した例 ではリストの最後にワイルドカードエントリが無いので、 ``ken'' と ``dennis'' と ``staff'' ネットグループと ``permitted-users'' ネットグループとを除く全てのユーザを システムは権限があるユーザとして認識しないでしょう。 ``rejected-users'' ネットグループは認識されますが、 全メンバのシェルは再マップされますので、 アクセスは拒否されるでしょう。他の全てのNISパスワードレコードは無視され るでしょう。 管理者は以下のようなワイルドカードエントリをリストの最後に 付けても良いでしょう。

    +:::::::::/usr/local/bin/go_away

このエントリは他の全てのエントリと一致しない全てのユーザを一挙にとらえる 働きをします。 /usr/local/bin/go_away は、システムにアクセスを許可されないユーザに伝えるメッセージを出力する短か いスクリプトまたはプログラムでしょう。 必ずしもログインアクセスを許可せずに、 特定のNISドメイン内の全ユーザをシステムが認識可能であることが望ましいときには、 このテクニックが有効なことがあります。 ログインシェルとシェルスクリプトを使用するときのセキュリティに関する事柄 について、上記のシェル欄の記述を参照してください。

この 上書き 機能の主な用途は、 管理者がNISクライアント上でアクセス制限を強化可能とすることです。 単に特定のネットグループに対してユーザを追加したり削除したりするだけで、 そのユーザにあるマシン群へのアクセスを許可し、 かつ他のマシン群へのアクセスを拒否することができます。 ネットグループデータベースもまた NIS 経由でアクセスできるので、 1 個所すなわち NIS マスタサーバからアクセス制限を管理できます。 一旦ホストのアクセスリストが /etc/master.passwd に設定されると、新にネットグループが作られない限りそれは再度変更する必要 はありません。

注釈

  NIS経由のシャドウパスワード
FreeBSD はシャドウパスワード法を採用しており、 ユーザの暗号化されたパスワードはスーパユーザだけが読み書き可能な /etc/master.passwd および /etc/spwd.db にのみに記憶されます。 暗号化されたパスワードをパスワード推測プログラムに通すことにより、 ユーザが他のユーザアカウントに対して不正アクセスすることを防ぐためです。 NIS にはパスワード隠蔽のための標準的な方法がありません。 これは、 パスワードデータを全てNISパスワードマップに置き換えることは、 FreeBSD のパスワード隠蔽システムのセキュリティを無効にしてしまうことを意味します。

FreeBSD にはこの問題を回避するのに役立つ少数の特別な特徴が備わっています。 FreeBSD NIS クライアントと FreeBSD NIS サーバとの間でパスワード隠蔽を実装することは可能です。 getpwent(3) ルーチンは /etc/master.passwd と同じデータを含む master.passwd.byname と master.passwd.byuid マップを検索します。マップが存在すれば FreeBSD は標準の passwd.byname および passwd.byuid マップの代りにそれらをユーザ認証に利用しようとします。 FreeBSD の ypserv(8) はまたクライアントの要求をチェックして、 クライアントの要求が特権ポートから来たことを確認します。 スーパユーザのみが特権ポートにアクセスすることが許されるので、 要求しているユーザがスーパユーザであるか否か判断可能です。 master.passwd マップにアクセスする権限の無いユーザからの全ての要求は拒否されるでしょう。 全てのユーザ認証プログラムはスーパユーザの権限で実行されるので、 ユーザの暗号化されたパスワードデータへの必要なアクセスを持ちますが、 通常ユーザはパスワード情報を含まない標準 passwd マップへのアクセスのみ許されます。

この特徴は FreeBSD 以外のシステムがある環境では利用できないことに注意してください。 また、ネットワーク に無制限にアクセスできる真に限定されたユーザは依然 master.passwd マップを危うくすることにも注意してください。

  NISの上書きに伴なうUIDおよびGIDの再マップ
SunOS や Sun の NIS コードを利用しているオペレーティングシステムとは異なり、 FreeBSD ではユーザがNIS passwd エントリ中の 全て の欄を上書きすることを許しています。例えば以下のような /etc/master.passwd エントリを考えてみましょう。

    +@foo-users:???:666:666:0:0:0:Bogus user:/home/bogus:/bin/bogus

このエントリにより、`foo-users' ネットグループ中の全てのユーザは、 UID、GID、パスワードを含めて 全て のパスワード情報を上書きされます。この結果、彼等のパスワードは不正な 値に再マップされるので、全ての `foo-users' はシステムから締め出さ れることになるでしょう。

以下のようにNISワイルドカードエントリを使う習慣のある人が多いので、 このことは覚えておくべき重要なことです。

    +:*:0:0:::

これはしばしば新米の FreeBSD 管理者が以下のように master.passwd ファイルのNISエントリを選んでしまうことにつながります。

    +:*:0:0::::::

更に悪く、以下のようにしてしまうこともあります。

    +::0:0::::::

master.passwd ファイルには「絶対に」このようなエントリは入れないでください!! 最初のものは、 全てのパスワードを `*' に再マップし (これは誰もログインできなくします)、 全ての UID および GID を 0 に再マップする (これは皆をスーパユーザにします) ことを FreeBSD に指示します。 2 番目のものは全 UID および GID をちょうど 0 にマップします が、これは 全てのユーザがrootになってしまう ことを意味します!

  NIS上書き評価の互換性
Sunが最初に getpwent(3) ルーチンにNISサポートを追加したとき、 SunOS のパスワードファイル /etc/passwd はプレーン ASCII フォーマットであるということが考慮されていました。 SunOS のドキュメントによれば、パスワードファイルに '+' エントリを付け加えると、 パスワードファイル中の '+' エントリがある位置に NIS パスワードデータベースの内容が「挿入」されます。例えば 管理者が /etc/passwd の中央に +:::::: エントリを置いた場合、 NIS パスワードマップの全体の内容が パスワードファイルの中央にコピーされたかのように現われるでしょう。 管理者が +:::::: エントリを /etc/passwd の中央と最後の両方に置けばNISパスワードマップは2度現われることになるでしょ う。すなわち 1 度目はそのファイルの中央に現れ、もう 1 度は最後に現れます (単純なワイルドカードの代りに上書きエントリを用いることで、 他の組み合わせが可能です)。

これに対し FreeBSD では単一の ASCII パスワードファイルを持つというわけではありません。 FreeBSD ではハッシュ化されたパスワードデータベースを持ちます。このデータベースで は最初や中央や最後を容易に定義できませんので、 SunOS に 100% 互換の手法を設計することは非常に困難です。例えば FreeBSD の getpwnam() 関数と getpwuid() 関数は、線形検索ではなくハッシュデータベースに直接問い合わせするように設計さ れています。パスワードデータベースが大きいシステムでは、 このアプローチの方が高速です。 しかしデータベースへ直接問い合わせを利用するとき、 システムは元のパスワードファイルの順序を知り得ませんし気にしませんので、 SunOS が使用するものと同じ上書き論理は容易に適用できません。

代りに FreeBSD では全ての NIS 上書きエントリを一緒のグループにまとめ、それらから 1 つ のフィルタを作ります。各 NIS パスワードエントリはちょうど 1 回上書きフィルタ に対して比較され、それに応じて取り扱われます。フィルタがエントリを変更せ ずに通すことを許すならエントリは変更されないものとして取り扱われ、フィルタ が欄の再マップを要求するなら欄は再マップされ、フィルタが明白な除外を要求 するなら(すなわちエントリが '-' 上書きと一致するなら)エントリは無視され、 エントリがフィルタ指定のどれとも一致しないならエントリは捨てられます。

また、NIS の '+' および '-' エントリ自身は、 /etc/master.passwd の中で指定された順序で取り扱われることに再度注意してください。 それ以外の方法で取り扱うと、予測不可能な振舞いとなってしまうからです。

結局のところ、データベースのパラダイムを保ちつつ FreeBSD では SunOS と非常によく似た動作を行いますが、 getpwent(3) 関数は SunOS のものとはいくぶん異なった振舞いをします。主な違いは以下の通りです。

•   NIS パスワードマップの各々のレコードは、ローカルパスワード空間のパスワードに 1 度だけマップすることができます。

•   NIS の '+' および '-' のエントリの位置は、 NIS パスワードレコードがパスワード空間にマップされる場所に 必ずしも影響を与えません。

あらゆる FreeBSD の構成のうち99%においてはNISクライアントの振舞いは SunOS や他の同種のシステムのそれと区別できないものとなるでしょう。それでもこれ らのアーキテクチャ的な違いを知っておくことは必要です。

  NIS上書きに関しネットグループの代りにグループを用いる
FreeBSD はネットグループではなくユーザグループに基づいた上書き照合を行なう能力 を提供します。例えば NIS エントリが以下のように指定されたとき、

    +@operator:::::::::

システムはまず `operator' と呼ばれるネットグループに対してユーザを 照合しようとします。 `operator' ネットグループが存在しないとき、 システムは代りに通常の `operator' グループに対して照合しようとします。

  FreeBSDの古いバージョンからの動作の変遷
FreeBSD のNIS/YPの取り扱いについてはいくつかのバグフィックスと改善がありました。 そのいくつかは動作上の変化をもたらしました。動作上の変化は一般に良い方向 にありますが、ユーザおよびシステム管理者がそれらについて知っておくことは 重要です。

1.  2.0.5 以前のバージョンでは、逆方向検索 (つまり getpwuid() を用いる) には上書きは適用されませんでした。つまり、 getpwuid() は getpwnam() が認識しないログイン名を返すことがありました。 これは現在では /etc/master.passwd で指定された上書きを全ての getpwent(3) 関数に適用することで解決されました。

2.  FreeBSD 2.0.5 以前では、ネットグループの上書きは全く動作しませんでした。 これは主に FreeBSD が NIS を通してネットグループを読むことをサポートしなかったことが原因です。 これもまた修正され、 SunOS や同種の NIS を使用可能なシステムと全く同様に、 ネットグループを指定可能となりました。

3.  FreeBSD は現在NISサーバの能力を持っており、標準第6版形式の passwd マップに加え master.passwd NIS マップの使用もサポートしています。このことは、NIS サーバとして FreeBSD システムを利用するなら、変更情報、有効期限の情報、クラス情報を指定可能であ るということを意味しています。

関連ファイル
/etc/passwd
    パスワードを除いた ASCII パスワードファイル
/etc/pwd.db
    パスワードを除いた db(3) 形式のパスワードデータベース
/etc/master.passwd
    パスワードの入った ASCII パスワードファイル
/etc/spwd.db
    パスワードの入った db(3) 形式のパスワードデータベース

関連項目
chpass(1), login(1), passwd(1), getpwent(3), login.conf(5), login_getclass(3), yp(4), login.conf(5), adduser(8), pwd_mkdb(8), pw(8), vipw(8)

バグ
ユーザ情報は他のどこか に入れるべき(そして結局は入れることになる)でしょう。

YP/NISパスワードデータベースでは、 普通のユーザには暗号化されたパスワードが見えてしまいます。したがって master.passwd マップのシャドウパスワードおよび FreeBSD の ypserv(8) サーバを利用しないと、 簡単にパスワードクラッキングを許してしまうことになります。

master.passwd タイプのマップの使用をサポートする FreeBSD の ypserv(8) を使用しないと、 YP/NIS パスワードデータベースは 古いスタイル (第 6 版) のフォーマットになります。これは、 FreeBSD システムを標準 NIS サーバのクライアントとして利用するとき、 ユーザのログインクラスやパスワード期限等の 現在のフォーマットにある欄の値については サイトワイドな値が利用できなくなることを意味します。

互換性
パスワードファイル形式は 4.3BSD 以降で変更されました。以下の awk スクリプトは、古いスタイルの パスワードファイルを新しいスタイルのパスワードファイルに 変換するのに利用できます。 “class”, “change”, “expire” 欄が追加されましたが、デフォルトでは無効になっています。 これらの欄を設定するには vipw(8) もしくは pw(8) を使用してください。

    BEGIN { FS = ":"}
    { print $1 ":" $2 ":" $3 ":" $4 "::0:0:" $5 ":" $6 ":" $7 }

歴史
passwd ファイルは AT&T UNIX で現われました。YP/NISの機能は SunOS を雛型として FreeBSD 1.1 で初めて現われました。上書き機能は FreeBSD 2.0 において新しく組み込まれました。上書き機能はネットグループを適切に サポートするために FreeBSD 2.0.5 で更新されました。注釈のサポートは FreeBSD 3.0 で初めてサポートされました。