デフォルトでは、ユーザーのために実行するプロセスとのコンソール対話を含むユーザーの作業ファイルを受け入れる必要があります。当然、最初に浮かぶアイデアは、expectスクリプトを作業ファイルとして使用することです。
spawn process
expect "ready"
send "process DATA"
set timeout 100
expect {
"done" {send_user "success"}
timeout {send_user "failure"}
}
しかし、自動的に作業を受け入れたいので、ユーザーが10のsysbenchプロセスを作成したり、ランダムなファイルをディスクに書き込んだり読んだりするなど、愚かなまたは危険なことを避けたいと思います/etc/passwd。私は生成されたプロセスがSTDIN / STDOUT相互作用を実行するために使用しています。
どうすればいいですか？これまでの私の考えは次のとおりです。
- 私自身の「期待ライト」を書いてください。実行可能なように聞こえますが、愚かで時間がかかります。
expect作業ファイルをクリーンアップします。複雑でエラーが発生しやすいようです。- 独自のセキュリティ言語を開発し、これを
expect。 - ワークフローを制限するには、クォータと権限を使用してください。
process多くのCPU時間を使用してtmpファイルを生成すると予想されるため、これは実際にはオプションではありません（ファイルをクリーンアップすると思います）。 - ユーザーに対話型アクセスを提供します
process。ジョブがキュー内でしばらく待つ必要があるため、これはオプションではありません。
expectスクリプトを制限する設定パラメータや利用可能な同様のツールなどの明らかなものがありませんか？
ベストアンサー1
TCLセキュリティコンバータはexpect。コードは次のとおりです。unsafe.expsafe.expunsafe.expunsafe.exp
#!/usr/bin/expect
spawn whoami
expect {
"user" { send_user "safe success\n" }
"root" { send_user "unsafe success\n" }
}
実行結果unsafe.expはroot
# expect unsafe.exp
spawn whoami
root
unsafe success
これで、ユーザーはsafe.exp.comや.comなどの危険なコマンドを使用できないようにブロックされますspawn。コードは次のとおりです。sendexpect
#!/usr/bin/expect
# create a safe interpreter
interp create -safe untrusted
# provide it with essetial expect functions
interp alias untrusted send_user {} send_user
interp alias untrusted send {} send
interp alias untrusted expect {} expect
interp alias untrusted interact {} interact
# censor the "spawn" function
# not providing it would be just as safe, but scripts using it would fail
proc safe_spawn {args} {
puts "censored spawn"
}
interp alias untrusted spawn {} safe_spawn
# create a safe process to interact with
spawn sudo -u user whoami
# run unsafe.exp
untrusted invokehidden source unsafe.exp
ルートとして実行すると、次のようなsafe.exp結果が得られます。
# expect safe.exp
spawn sudo -u user whoami
censored spawn
user
safe success