ptraceを無効化してないと、PTRACE_O_SUSPEND_SECCOMP で自由にseccompを無効化できてしまう。
などと書いてある文献を見つけたのでちょっと調査

なお、このコミットだった模様
 
commit 13c4a90119d28cfcb6b5bdd820c233b86c2b0237
Author: Tycho Andersen <tycho.andersen@canonical.com>
Date:   Sat Jun 13 09:02:48 2015 -0600

    seccomp: add ptrace options for suspend/resume

    This patch is the first step in enabling checkpoint/restore of processes
    with seccomp enabled.

    One of the things CRIU does while dumping tasks is inject code into them
    via ptrace to collect information that is only available to the process
    itself. However, if we are in a seccomp mode where these processes are
    prohibited from making these syscalls, then what CRIU does kills the task.

    This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
    a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
    filters to disable (and re-enable) seccomp filters for another task so that
    they can be successfully dumped (and restored). We restrict the set of
    processes that can disable seccomp through ptrace because although today
    ptrace can be used to bypass seccomp, there is some discussion of closing
    this loophole in the future and we would like this patch to not depend on
    that behavior and be future proofed for when it is removed.

    Note that seccomp can be suspended before any filters are actually
    installed; this behavior is useful on criu restore, so that we can suspend
    seccomp, restore the filters, unmap our restore code from the restored
    process' address space, and then resume the task by detaching and have the
    filters resumed as well.

 

ようするにseccompが有効化されてるコンテナでもCRIUしたいじゃんってことらしい。
えーと、gdbもCRIUも使いたいけど、seccomp迂回は限定したいって時はどうしたら・・・・??



このエントリーをはてなブックマークに追加

Money Forwardについての不満がいろいろ溜まってきたので忘れないようにメモる。超個人メモなので、気にしないように

MFのアプリを開くと目立つ所に資産総額と前日比が表示される。


前日比
 
わたしはこれが気に入らない。なぜ気に入らないのかしばらく自分でうまく言語化できなかったが、少しづつわかってきたので書いてみる。

まず、前日比が一見タップすると反応するように見えて、それは資産総額をタップされた事になっている
(タップの反応範囲がおかしい)ので、前日比の詳細を見たいのに、資産一覧(もってる口座一覧)が
出てきて非常に混乱する。
直感的なのは、前日比からの変化の原因になってレコード一覧が出てくることである
(前日付の支出全部と、変化のあった株一覧)

しかし、よく考えてみると、前日からの差分という考え方がMoney Forwardのサービスのありかたとマッチしていない。MFを使う以上はきっとユーザはいつもニコニコ現金払いではなくクレカなどで支払い、MFの自動記帳を
使っていると思う。ところがクレカのレコードは一週間に一度反映とか珍しくないので毎日速報なんて出ないのである。
よってこの前日比はただの飾りです偉い人にはそれがわからんのです状態。意味が無い。

このUIだとユーザにクレカよりも現金払いを推奨していることになるのだが、分かっているのだろうか?ダメUIなので、再考してほしい。週ごと、月ごとの差分なら株も現金もクレカも困らないのに。

・・・・・ということを後日MFの人にいうための備忘録。


 
このエントリーをはてなブックマークに追加

最近Rubyの著名デベロッパのakrさんがAPIデザインケーススタディという書籍を出版された。隙を見ては読んでいるのだけどこれが激烈に面白い。
役にも立たない一般原則とかいっさいすっ飛ばし、実例実例、また実例である。そしてすべての例がOSの制限やら過去との互換性やらいろいろな都合でトレードオフを勘案しながら取りうる選択肢のなかでのベストを見つけていくという題材になっているので話がどれもこれもが超面白い

みんな買おう。


それはさておき、一点だけちょっと微妙な記述をみつけたのでメモっておく。

P128からはじまる Column async-signal-safe関数 だけど
また、実際のところ、子プロセスでasync-signal-safeでない関数を使用す
るのは、珍しいことではありませんでした。たとえば、ネットワークサー
バの作り方の一つとして、クライアントからの接続のたびにforkを行い、
子プロセスでクライアントと通信する形態があります。この場合、子プロ
セスはexecしないので、POSIX的にはasync-signal-safeな関数しか使えませ
ん。しかし、実際にはさまざまな関数がかなり好き勝手に使われます。
 そのようなプログラムをサポートするため、多くのUnixではシングルス
レッドプログラムからforkで子プロセスを作った場合、async-signal-safeで
ない関数も問題なく動作するようになっています。ただし、その動作は
POSIXに反しているため、将来的にも動作が保証されるかはわかりません。

と書いてある(強調は筆者)んだけど、Open Group(現代ではPOSIXと同義)のforkのページを見ると(強調は筆者)
A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. 
なので、async-signal-safeの制限があるのは規格上も multi thread なプログラムだけである。わたしが規格をなにか見落としていないかぎり。




このエントリーをはてなブックマークに追加

transparent hugepage considered harmful のページ、Andreaが技術的な解説をしてくれたのでちょっと追記してみた。
このエントリーをはてなブックマークに追加

なんかスラドにあげられてしまったので、備忘録てきにちょっとまとめますかね。

きっかけは先月帰国したときに sonots がDeNAをはじめとして、Web企業では広く TCP_TIMEWAIT_LEN を変更してカーネルをリコンパイルして使っているという話を聞いたというもの。以下の様な議論を twitterで行い

Togetter: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://togetter.com/li/871768

以下のように、スラドに転載されてしまったわけだ。

スラド: Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味?: http://linux.srad.jp/story/15/09/09/0648258/

いつものように、スラド民は元のスレッドなんかまるで読んでいないので、結論だけ書く。
tcp_tw_interval という TIME-WAIT を変更するsysctlが3年ほど前にupstreamで提案されたが却下されている。

http://thread.gmane.org/gmane.linux.network/244411/

その時の議論の抜粋

・AIXではtcp_timewait というパラメタで、HP-UXでは tcp_time_wait_interval というパラメタで同種の機能(TIME-WAIT変更)がサポートされている。Solarisにも同種の機能あり
・tcp_tw_reuse や tcp_tw_recycle がすでにあるのは知ってるが、NATでうまくいかない時もあるじゃないか
・SO_REUSEADDR使え
・tcp_tw_reuse 使え
・tcp_max_tw_buckets 使え
・early time-wait reuse は validだけど、TIME-WAITを短くするのはたんに危険なだけで意味がない

まだまだ知見を募集中なので、ユースケースとか意見とかありましたら教えて下さい
このエントリーをはてなブックマークに追加

↑このページのトップヘ