Path: sran124!katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Message-ID: Date: 4 Sep 90 22:11:03 Organization: Software Research Associates, Inc.,Japan In-reply-to: nishi@trl.mei.co.jp's message of 3 Sep 90 05:10:36 GMT Newsgroups: fj.questions.unix Subject: Re: UID, GID Distribution: fj References: <7111@cefiro.trl.mei.co.jp> （Distribution: fj にしました。） 記事 <7111@cefiro.trl.mei.co.jp> で nishi@trl.mei.co.jp (Nishi Hiroyuki) さんいはく > ユーザＩＤ、グループＩＤはいくつまでの数字が扱えるのでしょうか？ > Sun の/usr/include/pwd.hでは、どちらもint 型になっています。 > ということは、何ビット３２ビットのデータが扱えるのでしょうか。 例えば sys/proc.h の中を見ると、struct proc の p_uid が short に なっていると思います。ですから、少なくとも 32bit 長は無理だといえます。 > -32768〜-32767までの１６ビットの符合付き整数なのでしょうか > このばあい、マイナスの値は使ってはいけないのでしょうか。 結論としては、現在のところ普通のユーザーに割り当てる場合には、 uid には負の値や 32767 を越える値は使わない方が無難だと感じています。 p_uid が short である一方で、sys/acct.h では struct acct の ac_uid が uid_t になっています。ここで uid_t は sys/types.h で unsigned short に typedef されています。つまりヘッダーファイルでの uid の符号の有無には一貫性がありません。（実装上でカバーされているのかも しれませんが、少なくともヘッダーファイル上では矛盾しています。）他にも、 cd /usr/include/sys; egrep 'uid' *.h などとやってみると面白いかもしれません。 上は SunOS(4.0.3) の場合ですが、BSD4.3 の場合は /usr/include/sys の 中の uid まわりは全て uid_t（やはり sys/typpes.h で unsigned short で あるように定義されている。）に統一されているものの、/usr/include/pwd.h だけは Sun と同様に int になってしまっています。 この矛盾に関連して現実にどういう不都合が起きるかについてですが、 例えば /etc/passwd に nobody:*:-2:-2::/: というエントリがあった時に、Sun でも BSD4.3 でも getpwuid(-2) は成功 getpwuid(65534) は失敗 するはずです。 この動作が正しいか間違っているかは私には判断がつきませんが、おそらく getpwuid のこの振舞いが影響して以下に述べるいくつかのコマンドが 32767 を越える uid や負（short の意味で負）の uid の元で変な動作をします。 まず負の uid を設定した場合、sa は -s をつけて summary file を作るときに 負の uid のもとで実行されたコマンドに対して「Preposterous user id」などと 誤った警告をします。lastcomm はユーザー名を uid の数字で表示(SunOS)したり、 正しく表示しなかったり(BSD4.3)します。 そうではなく、32767 を越える正の uid を設定した場合、今度は ps -u の USER のフィールドや、西さんが元記事でおっしゃっていたように ls -l の owner の表示が狂います。 （ちなみに、Gnu の ls は uid の正負大小にかかわらず正しく動く！） ＃ nobody:*:-2:100: ... ＃ nobody:*:65534:100: ... ＃ なんていうように /etc/passwd に２行かいておけば、ユーザー nobody に ＃ 関連していても、lastcomm も ps u も ls -l も sa -s もうまくいきます。 ＃ まさかこんなことは誰もやろうとしないでしょうが、この事実から、 ＃ (int)((unsigned short)-2) が -2 でなく 65534 であることと ＃ 問題のコマンド類の怪しい動作が密接に関連していることが推論できます。 私個人としては、pwd.h でも uid_t と定義されていて、さらに getpwuid(-2) も getpwuid(65534) も成功するようになっていたら、 いろいろ楽だったのではないかと考えてもいます。 -- ----____----____ 渡邊克宏　ＳＲＡソフトウェア工学研究所 Not execute, but evaluate.