検索

Perlの場合、setuidが立てられているスクリプトを実行しようとすると、自動的にTaintモードが発動するようである。(OSレベルのsetuidの有効・無効も絡むようではあるが・・・)

http://perldoc.jp/docs/perl/5.6.1/perlsec.pod
http://x68000.q-e-d.net/~68user/unix/pickup?setuid
http://x68000.q-e-d.net/~68user/webcgi/permission.html

などを参照のこと。
で、Taintモードだと

$arg = shift;

これ、汚染されてると見なされるみたい・・・。コマンドライン引数から指定された値を「そのまま」使うのはよろしくない。Taintモードにおいては。

• [ Prev ]
• [ Next ]
• [ 技術 ]

例えば、

bash: $ command1 >file 2>&1

だと、STDERRもSTDOUTもファイルにリダイレクトされる。
が、

bash: $ command1 2>&1 >file

だと、STDERRが画面に出力されてしまう。

http://x68000.q-e-d.net/~68user/unix/pickup?%A5%EA%A5%C0%A5%A4%A5%EC%A5%AF%A5%C8

にあるが、bashにおける"N>M"の機能は、内部的にはdup(M, N)(dup2?)をコールしている。
dup(M, N)の意は、MのファイルディスクリプタをNにコピーする。

すなわち、"N>M"の意は、Mの出力先ディスクリプタをNにコピーする。つまり、

bash: $ comman1 2>&1 >file

の意は・・・
１．2(STDERR)の出力先を、1(STDOUT)と同じくする。(=画面)
２．1(STDOUT)の出力先を、fileにする。
ということになる。よって、STDERRだけが画面に出力されるわけ。

逆に言えば、STDERRだけをlessりたい場合などは上記でオッケー。

リダイレクトはcshか、bashかによっても書き方が分かれるので忘れやすいところ。
見た目にもだまされやすい。
上記リンクを書きたかっただけじゃないかと言われればその通りだが、実際、忘れたときには上記リンク参照のこと。

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

例１：コマンド１の標準出力と標準エラー出力を「file.txt」にリダイレクトする。

bash:$ cmd1 &> file.txt
tcsh:$ cmd1 >& file.txt

例２：cmd1の標準出力を「file1.txt」へ、標準エラー出力を「file2.txt」へ。

bash:$ cmd1 1> file1.txt 2> file2.txt
tcsh:$ (cmd1 > file1.txt) >& file2.txt

備考：bashでは標準入力は「0」。tcshで括弧でくくった部分は別のシェルとして実行される。

例３：cmd1の標準エラー出力を「file.txt」へリダイレクト

bash:$ cmd1 2> file.txt
tcsh:$ (cmd1 > /dev/null) >& file.txt

例４：cmd1の標準出力と標準エラー出力をパイプを用いてcmd2へ渡す。

bash:$ cmd1 2>&1 | cmd2
tcsh:$ cmd1 |& cmd2

例５：cmd1の標準エラー出力をパイプを用いてcmd2へ渡す。

bash:$ (cmd 1> /dev/null) 2>&1 | cmd2
tcsh:$ (cmd1 > /dev/null) | cmd2

• [ Prev ]
• [ Next ]
• [ 技術 ]

• [ Prev ]
• [ Next ]
• [ 技術 ]

仕事先で憶えた小技。

#!/bin/sh -x

これをつけておくと、実行コマンド行が"+...."みたいな形で出力されるので、何をやっているのかが一目瞭然。

• [ Prev ]
• [ Next ]
• [ 技術 ]

暫く触っていないうちにすっかり分からなくなっていた setuid 系のパーミッション。

きっかけは、geno_squidsでsetuidするのを諦めた。が、fmlでは特に何もせずともML配下のvar/logなどに、fmlのユーザーで書き込めている。何故だ？

で、fmlの場合、ML配下のvarやspoolは、

drwx--S---  2 fml fml  4096 Jan 24 22:09 spool/
drwx--S---  2 fml fml  4096 Jan 24 22:09 tmp/
drwx--S---  5 fml fml  4096 Jan 24 22:09 var/

のように"S"がセットされる。→このフラグの意味を完全に忘れていた。というか、そもそも調べなかったのか。

"S"フラグは以下の形で設定できる。

$ chmod 0000 hoge
$ chmod g+s hoge

解説は以下を参照。
http://blog.livedoor.jp/dankogai/archives/50777535.html

ディレクトリにつけることで、ディレクトリのグループでファイルを作成できるらしい。委細は不明だが、だからfmlのvar, spoolにはSフラグが立っているのか・・・？しかし、Sフラグだけではファイルの作成はできないはず。実行権も付与しないと・・・。

っつーか、素でUNIXのパーミッションを忘れている自分が居る。

きっかけはgeno_squidsでsetuidを諦めたことだった。
ところが、fmlは特別な権限設定も無しに、fmlユーザーでMLディレクトリ配下のvar, spool に書けている。なぜ・・・？

違いは、以下のように ":include:" を経由しているか、いないかだった。

・geno_squidsの(今までの)記法

alias: "|/xxx/geno_squids.pl ..."

・fmlの記法

alias: :include:/var/spool/ml/hogeml/include
→/var/spool/ml/hogeml/include の中身：
"|/xxx/fml.pl /var/spool/ml/hogeml"

そう。fmlの場合、:include:を経由しているのだ。
試しに簡単なスクリプトを組んで、上記有無を適当なaliasを設定し試したところ、見事に上記の差異が再現できた。

どうも、:include: 経由だと、続くファイルの所有者・グループでもって、ファイルの中のパイプリダイレクトが動作するらしい。これがため、fmlはfmlのowneruid/gidでもってファイルを操作できていた。

では、:include: なしの、直接パイプリダイレクト(従来のgeno_squids)だとどうしても他のユーザでは動かせないのか？

sendmailの場合は不明だが、postfixの場合、回避策はある。main.cf で default_privs に、動作させたいユーザ名を設定する。

http://www.postfix-jp.info/trans-2.3/conf/main.cf.jp

これにより、以下のように制御できる。

:include:経由→従来通り、includeファイルのowneruid/gidで動作
直接パイプリダイレクト→default_privsで設定したユーザで動作

ipop3dを用いていると、出力されることがあるらしい。

実際、確認してみると /var/spool/mail ディレクトリ自体は 0775 のパーミッションだった。

http://tome.to/hiki/hiki.cgi?Fedora%A4%C7POP%A5%B5%A1%BC%A5%D0%A1%BC%A4%CE%C0%DF%C4%EA

単純にchmod 1777 すればいいだけらしい。

sendmailの場合は、/var/spool/mailqueueとかmqueueとかに一括して入っていたので、それを削ればメールキューを削除したりできた。

postfixになって、いろいろなディレクトリ間をステージに応じて移動されるようになった為、メールキューを整理・操作するには

postqueue
postcat
postsuper

などのコマンドを使用する必要があるらしい。

以下参照。
http://trombik.mine.nu/~cherry/w/index.php/2006/06/13/668/too-many-messages-in-queue

main.cfで、deafult_privsをlainユーザにした。でないと、geno_squidsがまともに動かない。
ファイルIOに関連するモジュールを大量に使っている為、迂闊にsetuid使ってTaintモードで動かせないし。
fmlは並走できるようなので、とりあえず十分。将来的にも、メールを用いた特殊な処理をさせたい場合は、業務アプリの範疇と見なし、lainユーザで動作させることに支障はない。まあ、:include:咬ませば、その先のファイルの所有uid/gidで動いてくれるから良いけど。

あと、/var/spool/mail ディレクトリを chmod 1777 実行。ipop3dがログにうるさかったので。

とりあえず書くところが無かったので、ここに。以上。

そんなこんなでIf-Modified-Sinceに対して 304 Not Modified を返すよう調整してみたら、

X-Pad avoid browser bug

というヘッダーが出力されるようになった。

・・・どうも、古いNetScapeNavigatorでは 256バイト(のN倍)のバイト境界に足らないとparseされないバグがあるらしい。ので、それを避ける為、ダミーデータをpaddingしているとのこと。

http://ml.php.gr.jp/pipermail/php-users/2003-December/019752.html

なのであんまり気にする必要はないみたい。

以上。