C++　フリーでぷろぐらみんぐ

POSIXとは？

Sun, 03 Aug 2008 09:02:27 +0900

UNIXベースのOSが備えるべき機能です。

つまり、POSIXで定義された機能はUNIXベースのOSであればどれでも使用できることになります。

LinuxでもほとんどPOSIXの要件は満たしているようです。（すべてかどうかは分かりませんが。。）

POSIX認定された機能を使用するとUNIX系のさまざまなOSに移行しやすいので便利です。

POSIXの機能として具体的には、mkdir()やsleep()などの関数が存在します。

似たような関数はWindows用の関数でも存在しますが、微妙に名前が違ったり、引数の数が意味が違ったりします。

これは注意点かと思います。

【WindowsとPOSIXを区別なく使用するには？】

たぶん、WindowsとPOSIXを隠蔽化してシームレスにディレクトリ作成の関数などを使用したくなると

思います。

このためには、一番いいのはBoostを使用することだと思います。

ディレクトリなどの操作であれば、以下のものがあります。

　・path.hpp

　・operations.hpp

　・error_code.hpp

　これらは、ディレクトリやファイルをイテレータで扱ったり、存在をチェックしたりでき、かなり便利な形で

　隠蔽化してくれています！

ただし、コンパイルが必要です。

＜自分で何とかしたい場合＞

もし自分で必要な関数だけ隠蔽化したければ、"boost/config.hpp"をincludeしましょう。

Boostのライブラリで、コンパイルは必要ありません。

これは、環境がWindowsかどうかを教えてくれる定義を提供してくれます。

具体的には、以下のような感じで使用します。

#if (defined BOOST_WINDOWS) && !(defined BOOST_DISABLE_WIN32)
　#include
　#include
#else
　#include
　#include
#endif

これでコンパイル時にWindowsなら上２つをincludeして、違えば下２つをincludeします。

資料が少なくて正確なところはわかりませんが、上記の感じで使用できると思います。

参考：

・Boostとは？

・ログ出力クラスを作成するには？

・CGIセッションのサンプル　←セッションファイルの削除の部分で使用しています
・IT用語辞典

・@ITでの説明

ログ出力クラスを作るには？

Tue, 29 Jul 2008 22:00:12 +0900

以前の記事で、ログ出力は難しい問題ということを書きました。

・ログ出力を実装する上での注意点とは？

そうはいっても、ある程度動くものを作ってみないことには感じもつかめません。

ここでは、WindowsやPOSIXの環境で使用できそうなログクラスを作ってみようと思います。

さて、boostにファイルロッククラスはありますが、ログ出力への使用は難しそうです。

そこでここではディレクトリ作成によるファイルロックを使用してサンプルを作ってみようと思います。

ファイルはこちら。

すぐに遊べるようにDev-C++とVC++2008のプロジェクトも入れてみました。

以下のファイルをダブルクリックしてみてください。

ビルド後にデバッグを起動するか、作成したexeを直接起動してみてください！

　Dev-C++　　⇒　stl_log/Project1.dev
　VC++2008　⇒　stl_log/log_vcprj/log.sln

【サンプル（mainのみ抜粋）】

#include
#include

//#include

#include "boost/progress.hpp"

#include "NLog.h"

using namespace nana;

//ログファクトリへの登録
void initLogMap()
{
    LogFactory::setLog(0, LogPtr(new Log(Log::INFO, "main",
        LogFileWriterAutoPtr(new DelayFileWriter("testlog.txt"))))
    );
    //
    LogFactory::setLog(1, LogPtr(new Log(Log::ERR, "log",
       LogFileWriterAutoPtr(new DelayFileWriter("testlog.txt"))))
    );
};

int main()
{
    // メモリリーク検出
    //_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

    initLogMap();

    //ログファクトリから取得してみる
    LogPtr log0 = LogFactory::getLog(0);
    log0->info("ファクトリーから取得");
    log0->flush();

    //直接ログオブジェクトを作成してみる
    Log log(Log::INFO, "main", LogFileWriterAutoPtr(new DelayFileWriter("testlog.txt")));

    {
        progress_timer pro;

        for(int i=0; i<1; ++i){
            log.err("エラーです");
            log.info("情報です");
            log.warning("警告です");
            log.printf(Log::INFO, "%d, %s 正常終了しました。いえーい", 12, "がんばれよ");
        }
    }

log.flush();

    system("PAUSE");

    return 0;
}

【出力】

2008/07/29 13:59:07 [INFO] [main] ファクトリーから取得
2008/07/29 13:59:07 [ERR] [main] エラーです
2008/07/29 13:59:07 [INFO] [main] 情報です
2008/07/29 13:59:07 [INFO] [main] 12, がんばれよ正常終了しました。いえーい

【Logクラスの一部を抜粋】

#if (defined BOOST_WINDOWS) && !(defined BOOST_DISABLE_WIN32)

inline void sleep(const long& msec){
::Sleep(static_cast(msec));
};

#else

inline void sleep(const long& msec){
::usleep(static_cast(msec*1000));
};

#endif

ファイルのロックはディレクトリにより実現しました。

ディレクトリによるロックの実現を阻むものに、mkdir()、sleep()関数がC++言語標準に存在しないことを

以前の記事で挙げました。

ここではmkdir()、sleep()関数が存在する、WindowsとPOSIXに対象をしぼりました。

しかし、そのmkdir()やsleep()も、微妙に関数名や引数が違います。

それをどのように吸収するかというと、上記コードです

WindowsかPOSIXかをコンパイラに認識させ、実装の記述を変えるための工夫です。

"boost/config.hpp"をincludeすることで上記のように#ifで関数の内容を

変えることができます！

【説明】

システムがディレクトリを作成する時に排他をするので、同名のディレクトリを作成しようとするとエラーにします。

これを利用した方法でファイルロックを実現しています。

エラーはプログラムで捕捉できるので、ロック用のディレクトリを作成してみてエラーになれば、既に存在することが分かります。（つまり、ファイルがロックされていることが分かります）

ロックされていた場合は、200ミリ秒ほどsleepしてその後に再度ロックを試みます。

＜ログ出力の方法＞

Log.hファイルを見てみましょう。

ファイルロックの方法を決めても、ログ出力のためにはいくつか選択肢があります。

今回は、以下の２つの方法を提供しています。

　①SimpleFileWriter

　　ログ出力のたびに、ロック⇒ファイルオープン⇒書き込み⇒ファイルクローズ⇒アンロック、をします。

　②DelayFileWriter

　　ログ出力は一時ファイルを作成して書き込みます。flush()関数などが呼ばれたときに、

　　一時ファイルの内容をログファイルに書き込みます。

まず①の方法での良いところは、必ず時系列でメッセージが出力されるということです。

デメリットは、どのスレッドやプロセスから出力されたかが分かりにくいことと、

毎回ファイルオープンとクローズをするので遅いということです。

②の良いところは、ログオブジェクトごとにメッセージがまとまるので、ある画面の処理メッセージが連続で出力されることと、①よりも処理が速いことです。

デメリットは、他のスレッドなどの処理メッセージを時系列で把握しにくいでことす。

＜クラス＞

おおまかに以下のクラスがあります。

・ファイルロッククラス（FileLock）　・・・ファイルをロックするクラスです。

・ファイル書き込みクラス（XxFileWriter）・・・ロッククラスを内部に保持し、ロックから書き込みまでを担当します。

・ログクラス(Log)　・・・ファイル書き込みクラスを内部に保持し、ログ書き込みに必要なロック処理などを

　　　　　　　　　　隠蔽して使いやすいインタフェースを提供します。

　　　　　　　　　　また、ログレベルの機能もこのクラスが担当します。

使用例：

Log log(Log::INFO, "main", LogFileWriterAutoPtr(new DelayFileWriter<FileLock>("testlog.txt")));

書き込みクラス（DelayFileWriter）はSimpleFileWriterrクラスと入れ替えられます！

入れ替えて遊んでみてください。

また、ファイルロッククラス（FileLock）や書き込みクラスは、自由に拡張できます。

他にも色々作ってみましょう！（＾＾）

＜ログファクトリー＞

将来性を考えてみると、スレッドごとやプロセスごとに別々にログオブジェクトが取得できると

ファイルロックの問題を解決できそうです。

そのためには、１つのオブジェクトからログを取得できるようにすると良いと思います。

そこで、ここではそこまで実装しませんが、とりあえずLogFactoryクラスを作成しました。

ログファクトリーは使用しなくても大丈夫です。

サンプルのmainを参考にしてみてください。

もっと詳しくは、doxygenでドキュメントを作成してみてくださいね。

参考：

・ログ出力を実装する上での注意点とは？

・ファイルロックをするには？(boostのfile_lock)

・Boostとは？

Boostのfile_lockクラスの和訳メモ

Thu, 24 Jul 2008 06:17:54 +0900

自分用のメモです。

この説明のてきとう訳です。

自分の場合いつも意訳しないと英語を理解できないので、余計な言葉を想像で補って訳を作ります。

ちなみに自分の高校時代の英語の成績は5段階で下から2番目です（＾＾）

あくまで自分用のメモですので、正確なところは各自でお調べください。

【訳：　Caution: Synchronization limitation】

・１つのfile_lockクラスが、同一のプロセスで動作している２つのスレッドを同期しようとする場合、

　動作不定になります。

・1つのプロセスが、同一のファイルを指す2つのfile_lockクラスを使用する場合、動作不定になります。

最初の制限は、主にPOSIXから来るものです。POSIXのファイルハンドルはプロセス単位の属性であり、
スレッド単位の属性ではないからです。
これが意味するところは、もし１つのスレッドがファイルロックオブジェクトを使ってファイルをロックしてしまうと、
（同じプロセスの）他のスレッドもそのファイルをロックしているように振舞うということです。
Windowsのファイルロックのメカニズムは、一方で、スレッドの同期の保障を提供します。
（POSIXの場合にはスレッドごとに別々にロックの所有権を持てなかったのに対して、）
Windowsの場合、あるスレッドが（他のスレッドによって）すでにロックされたファイルをロックしようとするとブロックされることになります。

2つ目の制限は、Windowsでは、ファイルロックの同期状態の情報が、ファイル記述子１つだけに結び付けられる、という事実に起因します。
これが意味するところは、もし（１つのプロセスで）2つのファイルロックオブジェクトが同一のファイルを指すように作成されたなら、同期は保障されないということです。
POSIXの場合、2つのファイル記述子が１つのファイルをロックするために使用されて、
そのうちの１つの記述子がクローズされたなら、呼び出しているプロセスがセットしたすべてのファイルロックは、クリアされます。

参考：

・ログ出力を実装する上での注意点とは？

・ファイルロックをするには？(boostのfile_lock)

ファイル記述子（Wiki）

ファイルロックをするには？(boostのfile_lock)

Tue, 22 Jul 2008 19:45:20 +0900

ログ出力などしようと思えばファイルのロックをしたくなります。

この記事は、ログ出力を実装する上での注意点とは？の続きです。

ファイルのロックは難しい問題です。

ここでは、Boostのfile_lockを使用したロックを実現してみます。

【準備】

まず、boostのfile_lockクラスは、コンパイルの必要がありません。

しかし、ちょっとバグがあります。

修正方法をまとめましたので、参考にして修正してみてください。

　boostのfile_lockのコンパイルエラーの回避方法

【サンプル】

#include
#include
#include
#include
#include

#include
#include

using namespace std;
using namespace boost;
using namespace boost::posix_time;
using namespace boost::interprocess;

int main()
{
//This throws if the file does not exist or it can't
//open it with read-write access!

    //ロックしたファイルは書き込みできないのでロック用のファイルを書き込みと別に作成。
     ofstream ofs_t("_lock_myfile.txt", ios_base::app);
     ofstream ofs("myfile.txt", ios_base::app);

    try{
       /*

コンストラクタではロックされません。
OSにファイルロック機構があるか？ファイルは存在するか？のみチェックします。

*/
interprocess::file_lock flock("_lock_myfile.txt");

      //ファイルロックできるまでに待つ時間を5秒にします。
       ptime pt = second_clock::universal_time();
       pt += seconds(5);

     //ファイルロックを試みます。5秒以内にロックできなければ例外を発生させます。
      if(!flock.timed_lock(pt)) throw runtime_error("lock is failed.");

      ofs << "fasfas" << endl;

      system("PAUSE");

    }catch(exception& e){
      cout << e.what() << endl;
    }

    system("PAUSE");

    return 0;
}

【実験】

以下のように実験してみてください。

サンプルでは、ロックを掛けたままPAUSEするようにしています。

ですので、exeを実行したら、もう一回exeを実行してください。

2回目の実行では、すぐにPAUSEされません。

それは、1回目のexe実行のロックを解除されるのを待っているのです。

待っている時間は5秒です。

5秒経ったら勝手に終了します。

そうしたら、何かキーを押して1回目の実行プロンプトを閉じてください。

そして、ファイル「myfile.txt」を開いてみてください。

2回exeを実行しているので、2行のデータが出力されるはずですが、2回目がロックされて出力できないので

1行しか出力されていません！

ロックが確認できましたよね！（＾＾）

【説明】

まず最初に、予想外の動きをしていたことを書いておきます。

上のサンプルを見ていただくと分かると思いますが、ファイルロックしているのは書き込みファイル「myfile.txt」ではなく、「_lock_myfile.txt」です。

なぜかというと、理由は分からないのですが、ロックしたファイルを書き込みできなかったからです。

これはバグなのか、Windowsの仕様なのかは分かりません。

ですので、ロック用のファイルを作成して、それをロックしました。

これでもファイルに同時に書き込まれることがないのは分かるでしょうか？

プログラムがみんな同じファイルをロックできるまで待っているので、

ファイルに書き込むプログラム以外はロック解除されるまで待っているのです。

こういうことも良くやることです。

さて、ではロックを実施するクラスの説明に移ろうと思います。

＜コンストラクタ＞

interprocess::file_lock flock("_lock_myfile.txt");

クラスを作成します。

コンストラクタはファイルの存在チェックと、ロック機構があるか？をチェックしているようです。

コンストラクタを起動するだけではファイルはロックされません。

注意点としては、ファイル存在チェック、ロック機構存在チェックでエラーになると

interprocess_exception　例外が発生します。

これは、exceptionから派生している例外クラスです。

＜ptimeについて＞

これは、時間を扱う汎用的なクラスで、ファイルロックと直接関係の無いクラスです。

POSIXを利用しているようです。簡単に時間の加減算ができます。

すみませんが、ここではあまり深く説明しません。

＜timed_lock()関数＞

if(!flock.timed_lock(pt)) throw runtime_error("lock is failed.");

ロックを掛け、所有権を取得する関数です。

他の誰かがロックを先に掛けている場合は、ロックが解除されるまで待ちます。

引数に時間を渡すことができ、指定の時刻までにロックが取得できないとロックをあきらめます。

引数の型はptimeです。

返り値は、成功時にtrueとなります。

何かエラーが発生した場合は、interprocess_exceptionが投げられます。

＜lock()関数＞

ここでは使用していませんが、もう一つのロックを掛ける関数です。

ただし、他の誰かが先にロックを掛けていた場合、その人がロックをはずすまで待ち続けます。

ちょっとけなげなロックです。

何かエラーが発生した場合は、interprocess_exceptionが投げられます。

＜unlock()関数＞

明示的にロックを解除する関数です。

ちなみにクラスが破壊されるときに自動でロック解除されます。

【補足】

このBoostのfile_lockクラスは、POSIXとWindowsの環境で使用できるようです。

2つの間のファイルロックなどのプログラミングの仕方は違うのですが、それらの違いを吸収したのが

file_lockクラスです。

使い方は吸収できましたが、どうも、それぞれの動作機構などまで吸収できなかったようです。

そのため、使用するときは以下のことを守って欲しいようです。

①１つのプロセスについて、file_lockオブジェクトの使用はファイル１つにつき１つだけにしてください。

②同じスレッドが、ロックしたファイルをロック解除するようにしてください。

③std::fstreamを使用してロックしたファイルに書き込む場合、そのファイルのロックをすべて解放するまで

　ファイルのクローズをしないでください。

※この説明のTo sum upを和訳しただけですが、英語はさっぱりなので間違っていたらすみません。

正確には英語の説明を参照ください。

　この内容が事実とすると、WEB用のログ出力には使用できないことになります。

　なぜなら、Apacheなどは１つのプロセスを起動してそこから複数のスレッドを作り、

　CGIを実行するからです。

　つまり、①に反することになります。

【おまけ】

英語だれか訳してくれるとうれしいなー。

というわけで、いろいろ頑張ってコマ送り的な読み方をすると、

OSによっては、ファイルのある位置からある位置までをロックする、といったことができるようです。

今のバージョン（boost1.35）では実装しませんでしたが、Comming　Soon的なことが書かれているようです。

ほんとかな

日本語で説明したサイトや文献が全然なく、この記事の内容は少し不安です。

すみませんが正確な情報はBoostのサイトで取得をお願いします。

もうしわけないです

参考：

・ログ出力を実装する上での注意点とは？

・ログ出力クラスを作成するには？

・boostのfile_lockのコンパイルエラーの回避方法

・Boostのfile_lockクラスの和訳メモ

Boostのファイルロックの説明

Boostのfile_lockのリファレンス
Apacheとプロセスについてちょっと書いてある記事

boostのfile_lockのコンパイルエラーの回避方法

Tue, 22 Jul 2008 19:45:03 +0900

Boostのfile_lockはincludeするとそのままではコンパイルエラーになります。（ver.1.35）

もおー。困った子ねー。

ということで、回避方法を書いてみようと思います。

ただ、正式なHPなどに書いてあったものを見たわけではなく、いろいろ参考に独自に自分で試した結果なので間違っているかもしれないです。

ご了承ください。

対象：

Boostバージョン1.35のfile_lockに関わる箇所のみの修正です。

【ファイルの修正方法】

①文字化けの修正

　interprocess/detail/config_begin.hpp
　　⇒20行目　non ・DLL-interfaceの・を削除する

　interprocess/errors.hpp
　　⇒13,14行目　などの・やウの半角のような文字を削除する

②コードの修正（file_lock.hppだけです）　interprocess/sync/file_lock.hpp

　●165行目あたり：　同じ関数定義が2度記述されているのでコメントアウトする。

　/*
bool timed_acquire_file_lock
(file_handle_t hnd, bool &acquired, const boost::posix_time::ptime &abs_time)
{

　　・・・中略

}
　　*/←232行目あたり

/// @endcond

　●133,164行目あたり：　以下を追記
　// relinquish current time slice
#if (defined BOOST_WINDOWS) && !(defined BOOST_DISABLE_WIN32)
winapi::sched_yield();
#else
::sleep(0);
#endif

　●271行目あたり：　detail:: を削除する
　if(!timed_acquire_file_lock(m_file_hnd, result, abs_time)){

　●307行目あたり：　detail:: を削除する
　if(!timed_acquire_file_lock_sharable(m_file_hnd, result, abs_time)){

　●212行目あたり：　detail:: を追記する
　if(!detail::try_acquire_file_lock_sharable(hnd, acquired))

　●150行目あたり：　detail:: を追記する
　if(!detail::try_acquire_file_lock_sharable(hnd, acquired))

　●119行目あたり：　detail:: を追記する
　if(!detail::try_acquire_file_lock(hnd, acquired))

これで動くはずです。たぶん。

記載漏れはないと思うのだけどな。（ちょっと不安）

参考：

・ログ出力を実装する上での注意点とは？

・ファイルロックをするには？(boostのfile_lock)

ログ出力を実装する上での注意点とは？

Mon, 21 Jul 2008 09:57:52 +0900

Javaにはログ出力のクラスが標準で存在し、またApacheから別の強力なライブラリも提供されています。

うらやましいですね。

でも、C++には標準でログ出力クラスのようなものは存在しません。

それでも昔は、ファイルに書き出すだけなのでそんなに難しくないから自作すればいいじゃない、と高を括ってました。

すみませんでした。今は違います。

「だれか標準でどの環境でも使用できるログ出力クラスを作ってください！どうかお願いします」

と短冊に書いてしまうほどです。（笑）

ここでは、どんなところが難しいのかを書いてみようと思います。

【ログ出力の実装における注意点】

ロックを掛けないとファイルが壊れる

　初心者ですとイメージできないかも知れないですね。

　ファイルを2つのスレッドから同時にオープンして、同時に書き込むとファイルが壊れてしまいます。

　「そもそも2つのスレッドから同時にオープンなんてレアケースでしょ！」って思います？

　でも、WEBはこのケースですよ。

　CGIのプログラムを書いているとついついシングルスレッドのように錯覚しますが、

　実際にはApacheなどがいくつもスレッドを立ち上げて、IEなどのクライアントからの要求を同時に

　受け付けます。

　ですので、ログファイルに複数のスレッドから同時にアクセスされることを考慮しないといけません。

補足：

ちなみにファイルへの同時書き込みでファイルが壊れる現象は、別にログ出力だけに見られるものでは

ありません。

例えばOracleを２つ立ち上げて、１つが落ちてしまったときにもう一つに切り替えて、断時間を少なくするケースでも見られます。

サーバは２つ立ててハードディスクは１つを共有するということができるのですが、

切り替えのプログラムなどがファイルロックをしていないと、タイミングによってはOracle２つから同時に書き込まれて、ファイル（REDOファイル等）が壊れるのは良くあることです。

SEはこの辺は十分勉強してプログラムを作らないといけませんよね。大変ですけど・・・。

システムでファイルロックを実装していない環境がある

　じゃあ、ファイルロックを掛ければいいだけじゃない！と思いますよね？

　それがまた罠があります。

　システムからファイルロックを提供されていない環境があるのです。

　例えばWindows98やMeです。

　Linux系でもあるかもしれないです。

ファイルロックがC++標準に存在しない

　上の事情が関係していると思うのですが、C++標準ではファイルロック関数やクラスが存在しません。

　つまり、さまざまなコンパイラでコンパイルが通るようにしようと考えた場合、困ってしまいます。

　もう、Windows限定としてしまえば問題は無いかもしれないですが。。

ディレクトリ作成を利用したファイルロック

　さて、じゃあシステムで用意されない環境ではファイルロックを実現する方法はないのでしょうか？

　逃げ道はなくもありません。

　良くやる手は、ディレクトリ作成における排他機能を利用するのです。

　ディレクトリを作成することはおそらくどのOSでもでき、C標準ではないですがmkdir()という関数もあります。

　しかも、同じ名前のディレクトリを作成しようとするとエラーになったことを教えてくれます。

　これを利用します。

　bool lockfile(const string& filename){

　　string lock("_");

　　lock += filename;

　　if(mkdir(lock.c_str())) return false;

　　return true;

　}

　こんな感じです。

　ロックを解除するときは、ディレクトリを削除すればよいですよね。（＾＾）

　ディレクトリを作成する分、遅くなります。

　が、最近のHDDは速いし、これで十分でしょ、って思います。

　ロックに関してはシステムによるファイルロックとスピード以外には遜色ないかも知れません。

ロックに失敗したとき

　でも、問題はそう単純ではないのです。

　ログ出力以外ではロックに失敗した場合、「他の人が編集してます」というエラーを出してプログラムを

　終了しても良いかも知れません。

　しかしログ出力の場合、ロックが解除されるのを待って書き込まないといけません。

　このままでは、他のスレッドが先にファイルをロックしていたときに、ロック解除するまで

　待ってくれないのです。

　普通は、一定時間sleepしてもう一度ロックに挑戦して、書き込みをします。

　3回くらい失敗したらもうあきらめてエラー処理に移したりします。

　でも、sleepさせる関数がC標準には存在しません。

　もしforループで何百万回とかまわせば少しは時間を稼げ、その間に他のスレッドの処理が終わり、

　ロックが解除される可能性はあります。

　しかしこの方法は異常に負荷が上がってしまう可能性があるのです。

こんな風にログ出力の機能というのは、いろいろな問題が絡んでいて泣きそうです。

環境に合わせて作っていくしかないのでしょうね。きっと。

助け舟としては、Boostが提供してくれるfile_lock.hppがあります。

今日調べて実験した限りでは、ロック解除待ちもしてくれるようです。

ただし、Boostの古いバージョンでは存在しません。バージョン1.35(現最新)以降を参照してみてください。

　08.07.23追記：　

　Boostのfile_lockは、WEBなどのマルチスレッドでのログ出力には向かなそうです。

　詳しくは、下の参考の「ファイルをロックするには？」を読んでみてください。

とりあえずここでは、「難しい問題」ということが分かってもらえるとうれしいです！

参考：

・ファイルロックをするには？(boostのfile_lock)

・ログ出力クラスを作成するには？

Boostのfile_lockのリファレンス

SQLインジェクションとは？

Fri, 18 Jul 2008 19:31:58 +0900

セキュリティ関連でよく言われますよね。

でも、インジェクションの脆弱性はSQLだけではないのです。

まず、インジェクションという言葉の意味ですが、「注入」と言う意味です。

何を注入するかと言うと、「悪意」です（笑）

はい。

簡単に言うと、プログラム上に不備があり、注入された悪意をはじけないとセキュリティホールになります。

以下、具体的に見ていきましょう。

【SQLインジェクション】

例えば、ログインのIDとパスワードを認証することを考えます。

ユーザが入力したIDとパスワードを受け取ったところから考えてみましょう。

DBにSQL文でそのIDとパスワードが存在するかチェックに行きますよね？

＜入力＞

ID：　nana

PW：　july

＜SQL＞

ostringstream sql;

sql << "select id, pw from user where id='" << ID << "' and pw='" << PW << "'";

このプログラム、問題あるでしょうか？

おおありです！

ユーザがPWに「' or 0=0」と入力したらどうなるでしょう？

上のプログラムで作成されるSQL文は以下のようになります。

select id, pw from user where id='nana' and pw='' or 0=0

赤字がキーポイントです。

意味は、idフィールドが"nana"でpwフィールドが空文字の場合、

もしくは0が0と等しい場合、のレコードを返しなさい、となります。

当然ながら0と0はいつでも等しいので、全レコードを返すことになります。

これが先ほど言った「悪意」です。

解決策は、プレースホルダを使用するか、自分でSQLエスケープをすることです。

Javaの場合、JDBCのようなものがDB間の違いを吸収してくれます。

でもC++の場合、そのようなものは無いのでDBの提供するライブラリによって、プレースホルダがあったりなかったりします。

基本的には自分でSQLエスケープすることになるかと思います。

あとで、漏補で補足事項を書こうと思います。

【OSコマンドインジェクション】

これは、system（）関数にユーザが入力した値を使用する場合などにおきます。

良くある例では、sendmail を引き合いに出します。

http://www.thinkit.co.jp/cert/tech/7/5/4.htm

ここでは、ファイルをダウンロードさせる例を考えてみましょう。

WEBでユーザがファイル名のリンクを押すと、filename=sample.txt　などの引数が送信され、

そのファイルをダウンロードすることを考えます。

string file="sample.txt"; 　←ユーザ入力した値

ifstream(file.c_str());

このプログラム、問題あるでしょうか？

おおありです！

引数の値はユーザ側で改ざんして送信することができます。

改ざんした値が、../../../passwd.txtなどだったらどうでしょうか？

もしパスワードファイルがあればダウンロードできてしまします。

もちろんファイルのパスが分かっていることが前提となりますが、WEBサーバのOSと使用しているWEBサーバが分かるとたいていどこに何があるか分かってしまいます。

なので、とても危険なのです。

ピリオドやスラッシュ（/）、\を入力したらエラーではじくようにしましょう！

他にもセキュリティに関する注意点はいくつもあります。

十分調べてプログラム設計しておきましょう！

【漏補】

漏：

SQLのプレースホルダについてです。

プレースホルダを使用するとシングルクォートなどをエスケープしてくれて、インジェクションの攻撃から守ってくれます。

ただ、like　を使用する場合、難があります。

具体的にSQLを書いてみましょう。memoというフィールドが入力した単語を含むレコードを検索します。

select * from t_contents where memo like ?

では、%が無いのでだめです。　（?はプレースホルダです。）

例えば、ナナという文字を入力した場合上記のSQL文は以下のようになります。

select * from t_contents where memo like 'nana'

フィールドがnanaと完全一致するレコードしかひっかかりませんよね？

補：

これにはテクニックがあるのですが、結局自分でエスケープしないといけません。

以下のようにします。

select * from t_contents where memo like '%' || ? || '%'

意味、分かるでしょうか？

リプレース後のSQL文は以下のようになります。

select * from t_contents where memo like '%' || 'nana' || '%'

||は文字列連結なので、SQLの中で　like '%nana%' としているのと同じです。

これなら分かりますよね？

でもこれでは不十分です。

例えば「100%ジュース」という単語を含むレコードを探したい場合どうなるでしょうか？

上記と同じくリプレース後のSQLのlikeの部分だけ抜き出してみると、以下のようになります。

　like '%100%ジュース%'

これだと、100 とジュースが含まれるレコードが抽出されてしまいます。

なので、%と_をエスケープする必要があります。

(likeではこの２つが特殊文字です)

プレースホルダに代入する前にlikeエスケープをして、それから上記の　like '%' || ? || || '%' に代入しましょう。

Viewとは？

Tue, 15 Jul 2008 21:32:39 +0900

WEBやGUIアプリなどでよく言われる、MVCのうちのVを表すものです。

MVCそれぞれの意味は、以下のようになると思います。

M・・・モデル。　簡単にいうとデータです。

V・・・ビュー。　簡単にいうと見た目です。WEBで言うとHTMLといったところです。

C・・・コントローラー。　簡単に言うと、モデルを生成・処理したり、ビューに渡したりする全体の面倒見役です。

WEBではよくMVCと言われますが、普通のGUIのアプリでも良く使われる単語です。

WEBの専売特許というわけではありません。

さて、件のビューです。

WEBの話をしますと、

Javaでは、JSP、JSTLなどスタンダードなものがあります。

しかし、C++ではあまりスタンダードなものは無いと思います。

おそらく各自で独自に作成しているのではないでしょうか。

これだけだと記事として寂しいので、ちょっとGoogleで見つかったライブラリを紹介しておきます。

●Google Ctemplate

グーグルさんが公開しているライブラリです。

{{NAME}}で表された文字列を置換するようです。

このあたりが参考になるかもしれません。

　http://kdl.weblogs.jp/open/2008/07/google-ctemplat.html

　http://www.argv.org/~chome/ctemplate.html

●Azarac

ある会社さんが公開しているライブラリです。

JSPに近い動作のようです。

JSPの場合、初めてアクセスのあったJSPファイルは、Java言語のソースファイルに変換され、

そのソースファイルをコンパイルします。そして、コンパイルされた実行ファイルを実行する感じです。

ですので、1番最初のアクセスは遅いのですが、そのあとは実行ファイルが起動するだけなので

速くなります。

しかも、普通にJavaでコンパイルされたものを実行するので文字列を置換するより速くなります。

このAzaracも同じような動きをするようです。

詳しくはリンクを読んでみてください。

ちなみにC++勉強のためにこのブログでも作成しています。

よければ見て、遊んでみてください。

　　WEBデザイン（View）の拡張サンプル

参考：

・補足：WEBデザイン（View）の拡張サンプル

・MVCを実現するには？

補足：WEBのデザイン（View）の拡張サンプル

Tue, 15 Jul 2008 21:15:22 +0900

前回の記事・WEBデザイン（View）の拡張サンプルでは、デザインとロジックを分ける例を見てみました。

実際に作業効率を考える場合、これでは半分を埋めたにすぎません。

デザインとロジックを分ける理由は、主に以下のものになると思います。

　①保守性を上げる　（コンパイルなしにデザインを変更できる）

　②デザイナーとプログラマーが同時に開発作業ができる

前回の記事では①は満たしているけど、②は満たすとは限りません。

その理由と解決方法を以下で見てみます。

【デバッグツールについての補足】

デバッグツールは、
デザインファイルとデータファイルから出力ファイルを作成するツールです。
DesignStyleを使用するとデザイン(view)とロジックを分離できます。
しかし、DesignStyle::output() に代入するデータ(DesignData)は、
ロジック内で作成することになります。
つまり、ロジック部分が作成されコンパイルされないうちはデザインファイルの記述に間違いが無いかを確かめられず、デザイナーはプログラマが開発を終えるのを待たないといけません。
デバッグツールは、そんな問題を解決します。

debugtool.exe [引数1] [引数2] [引数3]

[引数1] ...データファイルパス。デフォルトdata.txt
[引数2] ...スタイルファイルパス。デフォルトstyle.txt
[引数3] ...結果出力ファイルパス。デフォルトout.txt

※このファイルと同じディレクトリにexeファイルをコピーすればお試しできます。
　（デフォルト値が働くので引数なしでとりあえず動作するはずです。）

【ツールの仕様】
データファイルからデザインデータ(DesignData)を作成します。
次にスタイルファイルを読み込み、作成したデータでoutput()を呼びます。
結果は、結果出力ファイルに出力します。

【データファイルの仕様】
使用できるタグとその意味。
サンプルdata.txtを参照してください。

・data データ(DesignDataSub)を表します。
　　　　属性：name・・・データ名を指定します。
　　　　属性：value・・・データを指定します。

・vec 配列（DesignDataVector）を表します。配列の要素は、配下にeleタグをおいて指定します。
　　　　属性：name・・・データ名を指定します。

・ele 配列の配下の要素を表します。このタグの配下には、data, vec, mapなどを指定できます。
　　　　
・map マップ(DesignDataMap)を表します。配下には、data, vec, mapなどを指定できます。

【デバッグ用のデータファイルのサンプル】

　
　　
　　nana@ne.jp"/ >
　
　
　　
　　nana@ne.jp"/ >
　
　
　　
　　nana@ne.jp"/ >
　
　
　　
　　nana@ne.jp"/ >
　　
　　　
　　
　

【スタイルファイルのサンプル】

redblue" >
　　

【サンプルの出力結果例】

0	備考です。何か？	お疲れ様です
1	備考です。何か？	お疲れ様です２
2	備考です。何か？	お疲れ様です３
3	備考です。何か？	お疲れ様です４

ほほー

詳しくは、実際にプログラムを動かしてみてください。

そう。

大きな開発時には、こういうツールを作るところまで気を配って開発をした方がいいと思います！

参考：

・WEBデザイン（View）の拡張サンプル

・Viewとは？

C++ フリーでぷろぐらみんぐ

目次

POSIXとは？

ログ出力クラスを作るには？

Boostのfile_lockクラスの和訳メモ

ファイルロックをするには？(boostのfile_lock)

boostのfile_lockのコンパイルエラーの回避方法

ログ出力を実装する上での注意点とは？

SQLインジェクションとは？

Viewとは？

補足：WEBのデザイン（View）の拡張サンプル

C++　フリーでぷろぐらみんぐ