無効なURLです。 プログラム設定の反映待ちである可能性があります。 しばらく時間をおいて再度アクセスをお試しください。
無効なURLです。 プログラム設定の反映待ちである可能性があります。 しばらく時間をおいて再度アクセスをお試しください。
環境変数に仕込まれたコードを実行してしまうBASHの脆弱性が CGIスクリプトに影響を与えるか試してみたら結果は悲惨な感じに Tweet 2014年9月25日 嶋田大貴 この記事は2014年のものです 朝から Bash specially-crafted environment variables code injection attack なるもので騒ぎになっていたので、さっそく手元の Apacheで試してみました。 /hoge.cgiというURIで実行されるように、一行のメッセージを出力するだけの CGIスクリプトを設置します。いっけん、なんの入力もクライアント側から受け付けていないため危険のありようもなく見えます。 #!/bin/sh echo "Content-type: text/plain" echo echo "Hi! I'm an ordinary CGI script w
プロセスがブロックする要因の一つにファイルI/Oがあります。これを同期I/Oと言いますが、POSIXではAIO(非同期 I/O、Asynchronous I/O)も定義しており、I/O中でもプロセスがブロックせず他の処理を進められるようになります。 本記事ではバッファキャッシュからファイル I/Oを解説し、Linuxのio_submit(2)を用いたPOSIX準拠のAIOライブラリを試作してみます。 ファイルI/Oとバッファキャッシュ io_submit(2)ではDirect I/Oを用いますが、ライブラリの試作へ進む前にまずファイルI/Oのバッファ(バッファキャッシュ)について整理します。実は単にバッファと言ってしまうと誤解される場面が多くあり、例えばプログラミング入門一般としてファイルI/Oを取り上げる際には、 CPUの動作は速い。ディスクの動作は遅い。 両者の間に速度差を緩和する緩衝
近況 飲んで帰ってきて、気づいたらこんなの書いていました。 ちょっと具体性に乏しいので、もう少し後でパッチを書きます。 (でも、明日は会社の歓迎会で飲んでくるのだ) 前回のあらましと今回見るところ 前回、仮想アドレスと物理アドレスの紐付けをする処理とそのデータ構造のページテーブルを見ました。 そして、今回はユーザ空間へのアドレス空間マップを行うmmap()を見ることで、仮想アドレス空間の扱いの一端をかいま見てみましょう。 mmapの実装 mmapは以下の実装である。 (厳密に言うと、システムコールのベクタではないので「システムコールの開始地点」ではない) asmlinkage long sys32_mmap(struct mmap_arg_struct32 __user *arg) { struct mmap_arg_struct32 a; if (copy_from_user(&a, a
Linuxでは、実行することでシステムに重大な影響を及ぼす操作がいくつもある。 今回は、全てのシステム領域を削除してしまうようなものだったり、重要データを削除してしまうような危険なコマンド7個を紹介する。 1.rm -rf rmコマンドでファイルを削除する際、このオプションを用いて削除することで非常に手っ取り早く作業を行う事が出来る…のだが、ちょっとしたタイプミスをしてしまった場合、消してしまってはいけないファイルも強制的に削除されてしまうこともある。 以下に例を記載しよう。 rm :ファイルを削除するコマンド。 rm -r :フォルダを指定することで、再帰的に中のファイルを削除する。 rm -f :削除確認無しに、強制的にファイルを削除する。 ここまでは問題無い使い方。実際に危険なのは、以下のコマンドになる。 rm -rf / :実行するとルートディレクトリ配下を強制的に削除する。 rm
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか? マジで分かってるか? マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか? そうだよ。お前多分、"-1"(forkのエラー通知)をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記という日記がとんでもなく読まれていてビビる。ブックマークもいっぱいついた。はてなブックマーク - Linuxとgitを作ったLinus - 未来のいつか/hyoshiokの日記 Linusがgitを2週間で作ったという話はわりと知られていなかったようなので、その話である。 gitっていつから作られているのだろうか。ということで、本家のリポジトリから引っ張ってくる。 $ git clone https://github.com/git/git わたしのしょぼいネット環境でも2分はかからない。 最初の10個のコミットは次のようになる。 $ git log --oneline|tail 9426167 Add "-lz" to link line to get in zlib. 7660a18 Add new fsck
Phoronixで知ったが、Linus TorvaldsがGCC 4.9.0のコード生成にブチ切れている。 問題はLinuxカーネルのload_balance()がランダムにパニックを起こすというもので、その原因は、報告者の使っているコンパイラーであるGCC 4.9.0のコード生成がおかしかったという話だ。 Linus様は御自ら生成されたコードを読み給い、平生と変わらぬ調子で物事の道理を示された。 Linux-Kernel Archive: Re: Random panic in load_balance() with 3.16-rc From: Linus Torvalds Date: Thu Jul 24 2014 - 14:47:25 EST On Wed, Jul 23, 2014 at 6:43 PM, Michel DÃnzer <michel@xxxxxxxxxxx> wro
プログラミング言語 malloc(3)のメモリ管理構造 2007/11/30 技術本部 クラウド基盤エキスパート 角馬 文彦 この記事の目次 malloc()といえばC言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.
rm -rf remains rm -rfの後に残りしもの 遊びのために、筆者は新しいLinuxサーバーを立ち上げて、rootでrm -rf /を実行して、何が残るかをみてみた。どうやら、今のrmというのは筆者のようなアホを相手にしなければならない未来に生きているようなので、実際に実行するには、--no-preserve-rootをつける必要があった。 # rm -rf --no-preserve-root / かかるおろかなる行為の後では、 /bin/ls /bin/cat /bin/chmod /usr/bin/file のような、偉大なるツールのたぐいはみな消え失せてしまった。まだ、ssh接続とbashセッションは生きているはずだ。つまり、bashの組み込みコマンドであるechoとかは残っているということだ。 Bashマクガイバーたれ root@rmrf:/# ls -bash: /
MeCab に至るまでの形態素解析器開発の歴史等はこちらをご覧ください メーリングリスト 一般ユーザ向けメーリングリスト 開発者向けメーリングリスト 新着情報 2012-01-27 MeCab 0.993 MeCab::Tagger::formatNode()が正しく動いていなかった問題の修正 スタックの消費を抑えるため、ほとんどのローカル変数(配列)をヒープ上に退避 2012-01-14 MeCab 0.992 ソースコード中のTypoの修正 2012-01-14 MeCab 0.991 空文字列もしくは空白文字列を解析した時に解析エラーとなる問題を修正 ユーザ辞書の作成に失敗する場合がある問題を修正 2011-12-24 MeCab 0.99 MeCab::Model, MeCab::Lattice クラスを追加 マルチスレッド環境でのユーザビリティの向上。複数スレッドが同一
systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald
3月版 2TBを超えろ! ATAディスクの4Kセクタ問題とは? 小崎資広 2010/4/7 前回書いたsys_membarrier()ですが、なかなかマージされない状態が続いています。だいたい議論も出尽くして後はマージするだけだと思っているのですが、どうもIngoは気に入らないご様子。たぶんオレ専用APIっぷりが美的感覚に合わないのでしょう。いつも「Genericに使えるように」っていいますから。 Compactionパッチは、マージの一番のネックだったkosakiがなかなかレビューしない問題は先月若干進展して、マージする方向で進んでいるみたいです。 さて、今月は久しぶりにハードウェアのお話です。ハードディスクの容量が2TiB(編注:テビバイト、1024GiB)を超えるのと前後して、4KiB(編注:キビバイト、1024bytes)セクタのハードディスクが出回り始めています。これについてハー
こんにちは。斎藤です。 最近、新しいスキー板が欲しいなと思っています。現在使っているOGASAKAの板は5年目に入り、メーカーからこれ以上はチューンナップ(メンテナンス)はできないよ、と言われてしまいました。もし、次に買うなら、スノーボーダーの人と一緒にパウダーに飛び込みやすいセミファットタイプが良いのかなと考えています。皆さんのオススメ、ぜひ教えてください。 さて、今日はLinux Kernel上でのメモリ管理、特にページ回収(Page Reclaim)とスワップに絞り、「スワップの理由」「ページを回収する仕組み」そして「スワップの様子を観察する」の3点に分けてお話しします。「スワップするのが気持ち悪い」と考えている方は少なくないと思いますし、私もそう考えていた時期がありました。しかし、それは本当に悪い事なのか、今回掘り下げて行きます。 ※主な対象Kernelは2.6.32(Red Ha
わりと長い間悩んでいたんだけど、最近解決したのでメモ。 サービスで利用しているsmalllightの画像変換サーバが、Apacheが使っているメモリ以上のメモリを使用し、Swapしたりメモリ枯渇でサーバがダウンするなどのことが何度かありました。 ↑メモリの動きはこんな感じ いろいろ調べた結果「dentry cache」なるものがメモリ多くを占めていることがわかりました。dentry cacheはディレクトリやファイル名とinodeとを結びつけに使われるキャッシュです。smalllightでは画像を変換する際に一時ファイルを作成するので、その情報が残るようです。 手元で再現させる 本番で使っているサーバはCentOS5系ですが、手元のVagrant上のCentOS6(ファイルシステムはext4)で、再現させてみました。 use Parallel::Prefork; use File::Tem
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
PHPだってシェル経由でないコマンド呼び出し機能が欲しい コマンド実行でシェルが怖いなら使わなければいいじゃない どちらの記事でも Python の subprocess を使ってシェルを介在せずにコマンドを実行する方法が紹介されています。 シェルを介在すると、エスケープの問題考えるのが面倒だったり、 kill してみたらシェルだけ殺して肝心のコマンドがずっと残ってるというアホみたいな問題を避けられるのでお勧めです。 いい子はこれを使いましょう。 この記事ではどうしてもシェルの機能が使いたい場合や、 subprocess の PIPE の組み立てが面倒な場合のための、バッドノウハウを紹介していきます。 ちなみに、バッドノウハウと呼んでるのは、安全安心 one size fits all ではなく、メリット・デメリット・やり方をいちいち調べないといけなくて、しかもその調べる行為がほとんどコン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く