ちゃっぴの監禁部屋

C/C++ の将来性その 3

ちゃっぴ (tyappi@wankuma.com) — Fri, 05 Sep 2008 03:44:00 GMT

Craf さんの書き込みより

あとちゃっぴさんの考察はデスクトップアプリや業務、Web系に偏ってる気がします。短期的には組み込み系、携帯端末アプリ(iPhoneとか)でC/C++需要が増えることは考えられるかと。ハードの能力が上がれば長期的にはPCとかと同じ道をたどるのでしょうけど。

こちらに関しては別の道もあるかもしれないですね。というのは、最近消費電力が注目されていますから。

現状では hardware level での消費電力削減が注目されていますが、将来的には software level での消費電力削減が必須だと主張している人もいますね。この主張をそのまま採用すると C/C++ の未来は明るいのかもしれません。

でも、個人的には software level での消費電力削減が必要とされるのは相当先の話になる気がします。というのは、一番削減すべきは idle 時の消費電力削減なんですが、これがまだまだ満足いくものになっていないと思いますから。

いくら CPU resource を利用しないように programming したとしても、現状では busy 時の消費電力削減が主になるんではないかと思います。これはこれで効果はあるんですが、CPU resource を使いまくるというのは結構少ないんですよね。

もっとも、組み込み用途は別だ！という人も多いと思います。確かに組み込み用途で要件が厳しい話をよく耳にします。ただ、そこまで性能を要求されない局面では Java 等の利用が増えていることから、なんとなく減っていきそうな気がします。

また、GC のような技術を採用した programming language がより進化しそうな気がしますし。

とりあえず、有言不実行の予告を書いておくと、次で oganac さんの意見に反論します。

引用元の筆者を追記

Progress bar

ちゃっぴ (tyappi@wankuma.com) — Fri, 05 Sep 2008 03:05:00 GMT

とりあえずこれ見てください。At Windows Vista Enterprise Edition です。

0% なのに。。。

さて、内部処理はどうなっているんでしょうね？

Progress bar を正確にすることの馬鹿らしさは分かっているつもりですが、それにしてもちょっとやりすぎの悪寒が。。。

二つ名

ちゃっぴ (tyappi@wankuma.com) — Tue, 02 Sep 2008 13:34:00 GMT

ちゃっぴさんの二つ名は…「虚構隠者（モノクロームミラージュ）」です

世捨て人らしいです。

C/C++ の将来性その 2

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Sep 2008 04:11:00 GMT

C/C++ の将来性の続き

多くの人から指摘されましたが、C/C++ はここ数十年では絶対に無くならないと思います。というのは絶対に必須な用途があるからです。

ただ、現在ではそういった用途以外でも利用されていることが多いのではないでしょうか？

正直、そういった用途では C/C++ の未来は暗いと思います。

C/C++がもたらす問題こういった問題があるので。

では、C/C++ の未来は暗いか？自分が発言した内容と矛盾しているようですが、一部のできる人にとって道は明るいかもしれません。

利用者は現在より一層減るでしょうけど、C/C++ programmer の価値は一層高まると思います。限定的な用途となりますが、C/C++ の問題点が一般的に認識されればど素人に扱わせるなんてこと無くなるでしょうから。
# 半ば以上、期待が含まれていることは否めませんが。

それから、必要も無いのに C/C++ で coding することもできれば避けるべきではないかと思います。今後一層 C/C++ programmer で問題なく coding できる人は減るでしょうから、保守で問題を生じる可能性がより一層高まると思われます。同時に費用面で問題が生じるでしょうし。

今後一層 C/C++ を扱う開発は減ってくる流れは強ますでしょう。そういう意味では、C/C++ は大衆受けする機能を盛り込むのではなく、一般的な開発者では扱えない機能をどんどん盛り込むことにこそ未来があるんじゃないかと思います。

Security を意識した発注をするためにはどうしたらいいんだろう？

ちゃっぴ (tyappi@wankuma.com) — Mon, 01 Sep 2008 02:23:00 GMT

第01回まっちゃ４４５勉強会でも話題に上ったことですが、security を一定以上に保つためには発注時から secuirty 要件を盛り込む必要がありますね。一般に公開されているものとしては下記があります。

JNSA セキュアシステム開発ガイドライン

でもね、正直ここまで意識した RFP って現状では厳しいと思うんですよ。ぶっちゃけ、発注する側ここら辺の問題全く理解していないことも多いですし。理解しなきゃいけないという人もいますが、正直厳しいと思うんですよね。

個人的には当然やった方がいいと思いますが、そうなると RFP に定義された実装はともかくとして、試験をちゃんと行う必要があり、費用面で折り合わない場合も多いと思います。

現実問題としては、security 要件を全く盛り込まない RFP も多いわけで、そういう意味でもとりあえず security 要件をどんなものであろうと盛り込むのが現実的じゃないかと思ったり。

C/C++ の将来性

ちゃっぴ (tyappi@wankuma.com) — Sun, 31 Aug 2008 23:16:00 GMT

わんくま同盟横浜勉強会 #1 で話題に上ったこと。

ちゃんと理解していないオイラが書くのもなんですが、やっぱり将来性がないと思う。
# 御大すみません。

多くの人が C/C++ は複雑すぎるというのが理由としてあげていましたが、もっと深刻な問題として security の問題があると思います。

多くの人がご存じのとおり、C/C++ で coding すると buffer overflow の問題を避けて通れません。このことを完璧に理解して、かつ対策を完璧に実践できるのであれば問題はありませんが、この手の問題に完璧はありません。

このことは現時点で最も脆弱性に気を使っていると思われる Microsoft でも脆弱性が無くならないことが証明していると思われます。

知らない人も結構いるでしょうけど、Microsoft は Trustworthy Computing の一環として SDL: Security Development Lifecycle を取り入れていますので、現状では security に関して一歩先に進んでいます。それでも、ご存知のとおり深刻な脆弱性は無くなっていません。
# Check-in するときに security に問題のある code を弾くことをやっているのはすごいですね。
# ぜひ、一般でも扱えるように展開してもらいたいものです。

私は基本的に software を開発する立場ではなく、software を扱う立場ですが、意識の差はあるにしろ少しでも脆弱性が少ない software を扱いたいというのは software を扱う者の共通した願望でしょう。

ということで、performance や機能の問題で C/C++ が必須とされる場合を除き、C#, VB, JAVA 等の memory 管理を自動で勝手にやってくれる言語で書いて欲しいと思っています。

ぶっちゃけ、C/C++ で全く脆弱性の存在しない code を書くのは非常に難しいです。ということで、C/C++ で書くのは本当にどうしようもない場合に限って欲しいなぁというのが願望です。

間違っても、programmer 一年目のど素人とかには絶対に手を出して欲しくないです。扱うなら下記を熟読し、完璧に理解した上で数年みっちり修業し、しかるべき code review を実施した上で release して欲しいものです。

C/C++ 扱う上で気にしなければならない security の問題点が説明されています。また、software の内部動作を理解する上でも役に立つでしょう。

Windows platform を扱うなら絶対に読んで欲しい本。Coding の問題点を指摘する書籍は他にもいろいろありますが、coding 以外の設計等で脆弱性を局所化することを説明している書籍は少ないのでぜひ一読すべき。
# ただし、個人的にはちょっと問題に思える部分があるので鵜呑みにしない方がいいと思われます。もっとも、それを差し引いても概念を理解するためには非常に役立ちます。

場所を変更するなら ACL までちゃんと意識しよう！

ちゃっぴ (tyappi@wankuma.com) — Sun, 31 Aug 2008 21:36:00 GMT

Default を変更することによって発生する脆弱性

以前、上記のような entry を書いたんですが、全く浸透していないようなのでもう一回書きます。

よくある tips の一つとして IIS で利用される virtual directory の場所を変更するというのがあります。

確かに、既定の %SYSTEMDRIVE% 配下にある Inetpub 以下を別の drive に変更することによって下記利点が得られます。

Directory traversal attack による影響の軽減
Disk full に対する影響の軽減
Disk fragmentation の影響の軽減

ですが、何も考えずに移動を行うと下記問題が発生します。

Default と違う ACL が適用されることによる脆弱性の発生
Default と違う ACL が適用されることによる動作の問題

Windows 2000 の場合、%SYSTEMDRIVE% 以外の drive は既定で everyone full control となっているため脆弱性の影響は甚大ですね。Windows XP 以降は drive root の ACL が強化されているので幾分マシ。ただし、まともに動かない可能性が出てきちゃいますね。

ではどうしたらよいか？

ACL も一緒に移せばいいんです。UNIX とかを扱う場合 copy する場合には permission を必ず確認するというのが当たり前なんですが、Windows 環境下だと気にしない人が多くて正直困ります。

具体的な方法としては Windows Server 2003 以前であれば "xcopy.exe" に /X を指定して ACL ごと copy するというのがお手軽ですね。Windows Vista 以降では "robocopy.exe" /COPY:DATSOU を利用すべきですね。

ただし、対象として指定した folder のみ ACL が複製され、上位は ACL が複製されないところに気をつけなければいけません。

これを解消するには、面倒ですけど上位の ACL を継承していない folder を割り出し、その folder に対して ACL を複製する必要があります。

この作業には "cacls.exe" が利用できます。Windows Server 2003 以降の "cacls.exe" には /s option が加わりました。/s のみを指定した場合、対象の SDDL を返します。

D:\Users\busby>cacls.exe "C:\inetpub" /s
C:\inetpub "D:PAI(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;OICIIO;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;FA;;;SY)(A;OICIIO;GA;;;SY)(A;;FA;;;BA)(A;OICIIO;GA;;;BA)(A;;0x1200a9;;;BU)(A;OICIIO;GXGR;;;BU)(A;;FA;;;SY)(A;OICIIO;GA;;;CO)"

こちらで得られた SDDL を /s: の後に付けることで、確実に ACL を複製できます。

Windows Vista 以降では "icacls.exe" の /save, /restore が利用できますね。Windows XP 以前では残念ながら標準ではうまい方法がありません。"SubInAcl.exe" を利用しないとダメですね。

自分で標準で設定されている ACL よりもより適切な ACL を付与できるなら別ですが、なかなかそこまで理解している人は少ないでしょう。実際、Windows Server 2003 以降の ACL はものすごく考え抜かれていて、標準の状態でまず問題がありません。ただし、Windows XP 以前だと結構穴が見つかるので、Windows Server 2003 以降の ACL を参考に手動で設定したほうがよいでしょう。

ということで、標準で設定された場所を移すのであれば、本来 ACL も意識しなければならないんです。よく高速化の tips や security の tips として標準から変更する手順が記事にありますが、この手の記事で ACL を意識しなさいと書いてあるものはほぼ見かけたことがありません。個人的には、この手の記事は正直脆弱性を助長しているとしか思えません。

ただ、変更することによって生じる利点も確かにありますから、その手の記事を書くのであれば、同時に ACL も一致するように設定する方法も記述してもらいたいものです。

もし、場所の変更のみ記述しているどうしようもない記事を見かけた場合には、脆弱性を助長していると報告してあげてください。

まっちゃ４４５に参加してみた

ちゃっぴ (tyappi@wankuma.com) — Sun, 24 Aug 2008 23:54:00 GMT

いろいろあって、だいぶ久し振りの entry になりました。

まっちゃ４４５こちらに参加してきました。

趣味で security 扱っているオイラと違い本職の人が結構いて大変ためになりました。

で、その専門家も現状の security には危機感を覚えているようで、最近では application level の脆弱性が多いこともあり、開発者と discussion したいという意見が多かったです。

ということで、10/4 にまっちゃ１３９とわんくまの合同勉強会があるらしい。

オイラもなんとか調整して参加したいと思っていますので、みなさん参加しましょう！

Windows Server 2008 で SQL Server 2005 Reporting Services Server を構成する方法

ちゃっぴ (tyappi@wankuma.com) — Mon, 04 Aug 2008 23:32:00 GMT

Windows Server 2008 上で Reporting Services をインストールおよび構成する方法

手元の Windows Server 2008 で試しましたが、上記で推奨されている [既定の構成をインストールする] だけではダメでした。

Install 直後、Report Server 側では (HTTP 403.1)、Report Manager では「リモートサーバーに接続できません」 (HTP 500) が発生します。

下記で確認できるので必ず稼動を確認しましょう。

Report Server
http://localhost/ReportServer[$<Instancename>]/
Report Manager
http://localhost/Reports[$<Instancename>]/

どうやら、IIS 側の設定がおかしいらしい。

[Reporting Service 構成] を起動し、 [レポートサーバー仮想ディレクトリ] および [レポートマネージャ仮想ディレクトリ] で [規定の設定を適用] した後、[Web サービス ID] で [レポートサーバー] 、 [レポートマネージャ] の application pool を「ReportServer[$<Instancename>]」に設定変更することで一応解消するみたいです。

IIS 7.0 で data directory を変更する方法

ちゃっぴ (tyappi@wankuma.com) — Mon, 04 Aug 2008 20:00:00 GMT

基本的には IIS 6.0 と一緒になりますが、若干違っている部分ありますね。

IIS の install

必要な機能を指定して install
inetpub の copy

# File の copy (ACL 付)
Robocopy.exe "%SYSTEMDRIVE%\inetpub" "D:\inetpub" /E /COPYALL

# Copy 元 inetpub の ACL 表示
# 出力された SDDL 形式の ACL は次の設定で利用する
cacls.exe "%SYSTEMDRIVE%\inetpub" /s

# Copy 先 inetpub の ACL 変更
cacls.exe "D:\inetpub" /S:"%SDDL 形式の ACL%"
普通に explorer 等で copy を実施した場合、ACL は copy されない。
この場合、Web application がうまく動作しなかったり、Web server が脆弱な状態になることがあるため、必ず ACL 毎移すようにするべき。
Metabase の編集

下記 file を backup した上で編集する

"%SYSTEMROOT%\System32\inetrv\config\applicationHost.config"

編集内容は "%SYSTEMDRIVE%\inetpub" を "D:\inetpub" に置換
IIS の再起動