「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。
Linux Capabilityの全てはこの式を噛み締めること。
意外と味がでてくる。
PはスレッドのCapability。
FはファイルのCapability。
ダッシュがついたら新しいCapability。
[important]
P'(permitted) = (P(inheritable) & F(inheritable)) | (F(permitted) & cap_bset)
P'(effective) = F(effective) ? P'(permitted) : 0
P'(inheritable) = P(inheritable)
[/important]
Permittedやらは前言ったとおりで、cap_bsetはbounding set。
Apache HTTP Serverでとても重要なhook関数。
必ず忘れて、The Apache Modules Bookを読みなおしちゃうのでまとめておく。
| 分類 | hook関数名 | 用途 |
| 設定初期化系 | ap_hook_open_logs() | ログのオープン |
| ap_hook_pre_config() | pre_config実行時 | |
| ap_hook_post_config() | initルーチンとかを呼ぶ時 | |
| ap_hook_optional_fn_retreive() | オプションとして登録された関数の取得 | |
| プロセス初期化系 | ap_hook_pre_mpm() | scoreboad作成時 |
| ap_hook_child_init() | 子プロセス起動直後 | |
| コネクション処理系 | ap_hook_create_connection() | コネクション処理時、あまり使わない |
| ap_hook_pre_connection() | コネクション処理の直前 | |
| ap_hook_process_connection() | プロトコルの処理時 | |
| リクエスト処理系 | ap_hook_create_request() | リクエスト生成時に、モジュールがrequest_configを生成したい時 |
| ap_hook_post_read_request() | リクエストが読み込まれてすぐに、モジュールでリクエストを処理したい時 | |
| ap_hook_quick_handler() | リクエストの処理が始まる前 | |
| ap_hook_translate_name() | URIをファイル名に変換する時、モジュールで変換したい時 | |
| ap_hook_map_to_storage() | モジュール自身のコンテキストに従ってper_dir_configを設定したい時 | |
| ap_hook_header_parser() | モジュールでヘッダを参照したい時、post_read_request()で代用 | |
| ap_hook_access_checker() | クライアントが認証受ける前に追加でアクセスチェックをしたい時 | |
| ap_hook_check_user_id() | リクエストヘッダからユーザーIDやパスワードの確認時 | |
| ap_hook_auth_checker() | リクエストされたリソースへのアクセスが認証されているか確認時 | |
| ap_hook_type_checker() | コンテントタイプ等を設定したりする時 | |
| ap_hook_fixups() | レスポンス内容の生成を変更する最後の機会 | |
| ap_hook_handler() | レスポンス内容の生成時 | |
| ap_hook_log_transaction() | レスポンス返した後のロギング時 | |
| エラー処理系 | ap_hook_insert_error_filter() | エラーの応答時にフィルターを挿入する時 |
| ap_hook_error_log() | エラーログ生成時 | |
| その他 | ap_hook_default_port() | リクエストで利用したデフォルトのポートを返す時 |
| ap_hook_http_scheme() | リクエストからHTTPメソッドを回収する時、用途はHTTPメソッドの容易な拡張 | |
| ap_hook_fatal_exception() | 例外処理時 | |
| ap_hook_get_mgmt_items() | 操作状況をモジュール提供 | |
| ap_hook_suexec_identity() | suexecのID取得 |
うーむ、多い。
これで今後の作業は楽になるだろう。
プロセスに関するLinux Capabilityには4種類のビットがあり、それぞれ役割が異なる。
[note]
P: Permitted
E: Effective
I: Inherited
B: Bounding
[/note]
この中で、プロセスがCapabilityを必要とする操作をOSに対して要求した際、評価されるのはEビットである。しかし、Eビットを決定する過程で他のビットも利用される。
Capabilityをセットする際、セットしたいCapability ＊以外＊ のCapabilityを落としすことでCapability機能を実現している。その ＊落とした＊ Capabilityを再度同じプロセスにセットし直せない様な仕様になっているのは、どういうリスクを想定しているのだろうか。
もう少し踏み込んでみよう。
例えば、あるプロセスにあるCapabilityのみをセットした状態にし、それ以外のCapabilityは落とした状態とする。
そこで、
「プロセスにセットしてあるCapabilityを一旦落とした後、再度、直前までセットしていたCapability ＊のみ＊ をセットし直すことは可能だ」
という仕様を許可することは、リスク的にどういったものが考えられるのだろうか？