Article 3994 of fj.unix: Path: news2.sra.co.jp!katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Newsgroups: fj.unix,fj.os.plan9 Subject: Re: Plan9 security (Re: reserved ports) Date: 7 Oct 1998 05:23:24 GMT Organization: Software Research Associates, Inc., Japan Lines: 54 Message-ID: <6vetsc$ln7$1@sranhh.sra.co.jp> References: <6j6bvf$ldc@ns4.synap.ne.jp> NNTP-Posting-Host: sras49.sra.co.jp In-reply-to: Kenji Arisawa's message of 11 May 1998 12:55:00 GMT Originator: katsu@sras49 Xref: news2.sra.co.jp fj.unix:3994 fj.os.plan9:127 あまりのフォローの遅さが議論の妨げになっていたらごめんなさい。 記事 で arisawa@vega2.aichi-u.ac.jp (Kenji Arisawa) さんいはく > 有澤@愛知大学です > > >テキストセグメントが書き込み禁止なのは共有のためだと思いますが…。 > UNIX ではもともとこのような意識は希薄だと思います。 > UNIX like な OS である OS9 は小さなメモリ空間で動作する必要があったので > 共有を徹底的に追求していました。 OS-9 から比べれば UNIX の共有への努力は全般には「希薄」かもしれません。 でもこの場合は、共有（による主記憶の有効利用）が理由だと思います。 実際、共有されないテキスト(see OMAGIC in a.out(5))ならば、 書き込み可能のまま現在に至っているのですから。 共有テキストセグメントが書き込み禁止なのは、共有に伴ってセキュリティの 問題が発生するからでしょう。異なる (effective) uid のプロセス間で 共有されている共有テキストが万一書き込み可能だったら、セキュリティ上 問題があるのは自明です。 > 最近はメモリがたっぷり使えるので僕も意識が希薄になってきたのですが、 > 以下の例ではどのように共有関係が実現されているのでしょう。 > Linux や FreeBSD ではこのへんの情報は見られるようになっているはずです。 > (僕はNEXTなので詳しい事はわからない) > 1. fork によって生成されたクローン > 2. 単なるコマンドによって生成された同一のプログラム(sticky bit 無し) > 3. 単なるコマンドによって生成された同一のプログラム(sticky bit あり) > 僕の予想では、1 と 3 は物理的にテキストを共有していると思いますが、 > 2 では共有していないと思います。(間違っているようでしたら指摘して > 下さい) 私の知る限りのあらゆる UNIX (*) で、1,2,3 いずれのケースも テキストが共有されます。なぜならば、execve(textfile, ...) は、 テキストの同一性を textfile の inode(や vnode) で判定するからです。 sticky bit は共有に関しては無関係です。 もちろん OMAGIC のケースは例外です。 関連する記事が http://www.sra.co.jp/people/katsu/article/174.text にあります。（ただし、テキスト共有とは関係ない部分で誤りが含まれて います。気になる方は、 http://www.sra.co.jp/people/katsu/article/#texttable の一連の記事を参照してください。） (*) V6以降、とりわけ BSD・System V など。4.4BSD Lite 由来の PC-UNIX 群。Linux。NeXT 等、Mach 上の UNIX サーバ。他。 ただし、共有を具体的にどう実現してるかは色々と異なる。 -- 渡邊克宏＠ＳＲＡ