また、Samba がなくても「ホスト間でのファイル共有」という需要はもともと存在してます。Microsoft Network の前に NetWare 等があった訳ですが、その辺りの存在は無視ですか? これらがコンシューマベースに降りて行った結果が Microsoft Network であり、ホームサーバとしての存在だとしか思えません。
そもそも Samba なんてない頃から MS-DOS マシンや Windows マシン間でファイル共有を行っていた身としては、Samba がなかったら組み込み向け Windows などの存在でファイルサーバという市場が形成されていただけだろうと思います。当然、今ある製品よりもライセンスフィーなどで高くなったでしょうが。
NTFS (スコア:2, 興味深い)
Re:NTFS (スコア:1, 参考になる)
NTFS の仕様を公開する (特にオープンソース製品により操作できる) 必要性が分かりません。今回の仕様公開における範囲は「OS や各製品群の仕様書を公開する」物ではないですよね。
もうちょっと突っ込んで言うと「Windows が NTFS を操作するために利用している API の一覧や関連パテント群」は公開されても、実装は公開されない。Windows をオープンソース化して丸裸にする訳ではなく、いわゆる「オープン化」する (プロトコルとなる API の仕様をすべて開示する) だけに過ぎないのではないでしょうか。
なので、今回の事で Windows の機能を利用してアクセスしている訳ではない ntfs-3g 等の実装が良くなる、というのは考えにくい話です。
つーか、操作を想定していない外部から自由に「読み書き」できるのは fs を破壊し、ACLs を無視する操作に繋がるので勘弁してくれって感じなのですが。
Re: (スコア:0)
これらをリバースエンジニアリングして作られているところのSambaとかrdesktop
(実際にはSambaは以前にもプロトコル文書を入手できたはずですが)
はプロトコルのドキュメンテーションを得られることで、
「もしかしたら」バグが修正できるかもしれません。
例えば世の中にSambaが無ければホームサーバという市場領域は形成されなかっただろうし、
企業内のWindowsネットワークも非常に制限された機能性しか提供できなかったでしょう。
同じように、NTFSをオープンソース製品なりなんなりでサポートするということは
MSにとってもそれなりの利益が有るはずです。
もっとも、今はNTFSよりもexFATとか別のネットワークテクノロジとかに注目して欲しいんだと思いますが。。
Re:NTFS (スコア:1, オフトピック)
良く考えてください。SMB(CIFS) も RDP も「プロトコル」です。NTFS は Windows における fs の「実装」でしかありません。公開されたプロトコルをベースに正しく通信を行う事ができれば十分であり、「実装の出来」でより良い実装が採用される競争が発生するのです。
*NIX であっても、NFS の下で現実に動いている fs が ufs/ext3/jfs/xfs... といったものは問いませんよね。それと何ら違いはありません。
で、それはともかく、「NTFS をオープンソース製品なりでサポートできる」事が、直ちにメリットになるとは言い切れません。現状において「NTFS が信頼するに値しないファイルシステムではない」訳ではありません。(アホみたいに多いインストールベースで現実にここまで検証されている fs は FAT しか存在しない!)
NTFS の仕様を完全公開してパテント料を無償で公開する事により、ntfs-3g のような無償系の NTFS へアクセスを可能にするツールの機能を向上し、万が一 Windows が起動しなかった場合にデータリカバリがしやすくなる、といった程度のカスみたいなメリットしか得られません。逆に、Windows 系列のマシンが盗難に遭い、ACLs を無視して自由に「OS の外から」システムやデータを格納する fs に対し、自由に操作する手段を提供する可能性が上がる方が危険でしょう。
Windows と *NIX 間においては NFS/CIFS を用いて各 OS がどのような fs を採用していようが通信可能な状態が既に確保されています。Windows 上で日常的にバックアップを取っていれば NTFS がおかしかろうがディスクが破損しようが NTFS がどうこうというのは関係のない話としか言えません。
NTFS の仕様が公開されない事で「Windows の独占的な地位が保証される」くらいの強い理由がなければ、公開される理由も必要もないでしょう。
あと、ZFS のパテント問題が再燃してますね。こういう問題が出た時に、MS が泥をかぶってオープンソース勢を守ってくれるとか思えますか?
また、Samba がなくても「ホスト間でのファイル共有」という需要はもともと存在してます。Microsoft Network の前に NetWare 等があった訳ですが、その辺りの存在は無視ですか? これらがコンシューマベースに降りて行った結果が Microsoft Network であり、ホームサーバとしての存在だとしか思えません。
そもそも Samba なんてない頃から MS-DOS マシンや Windows マシン間でファイル共有を行っていた身としては、Samba がなかったら組み込み向け Windows などの存在でファイルサーバという市場が形成されていただけだろうと思います。当然、今ある製品よりもライセンスフィーなどで高くなったでしょうが。
Re: (スコア:0)
>逆に、Windows 系列のマシンが盗難に遭い、ACLs を無視して自由に「OS の外から」システムやデータを格納する fs に対し、自由に操作する手段を提供する可能性が上がる方が危険でしょう。
これでは暗号化でいうと「アルゴリズムを秘密にしているから安全」理論です。
実のところ、NTFS ACL を設定してあっても、他の Windows マシンにマウントすれば
読み書きできるはずですのでオープンソース NTFS 実装が出たところで危険性は変わりません。
これに対する根本の対策は、Vista で導入されている BitLocker になります。
(3rd パーティ製暗号化ソリューションでもかまいませんが。)
Re:NTFS (スコア:1, すばらしい洞察)
ポイントがちょっとずれてる気もします。
他の Windows 機に接続してデータを抜き出そうとした場合、それは適切に ACLs の制約を受けた状態でアクセスすることとなります。例えば C:\Users\(ユーザ) フォルダ以下から Administrators の読み出し権限を取り除いておくと Administrators に所属しているユーザでも読み取る事はできません。
ただし Administrator ならアクセス権限の変更が可能 & 組み込み Administrator の GUID は固定であることから、Administrator としてアクセス権限を取得して読み出し可能ですが、これは別の問題です。
こうした HDD を他のマシンへ移す場合においては、BitLocker などのようなソリューションでないと安全性が担保できないのは同意です。
しかし、ACLs や MAC といったアクセス制御機構を利用していてもこれらを全く無視されたらそのままアクセス可能になります。Administrator への昇格等すら全く不要な状態で、他 OS 管理下の fs を操作できることになります。
例えば安全性を高めるために、今後 Windows プラットフォーム下では TPM 必須で自動的に EFS/BitLocker を有効にするように変更、ということがあったとしましょう。しかし、そこは「内部の実装レベル」の話であり、公開情報としてどのようにしたらアクセスできるようになるという情報は出す必要は全くないですよね。
しかし、これを公開した場合、マシンが盗難された時に EFS/BitLocker を使っていても、該当マシンで Knoppix を起動して ntfs-3g 改で TPM (秘密鍵) を利用して適切に暗号化を解除してデータを取り出せます、なんてのはデメリットが大きすぎじゃないでしょうか。
秘密鍵もセットで (マシンごと) 盗まれても、暗号化ロジックまで公開してなければ容易に取り出すことが出来ない方が (少なくともこの場合においては) マシだと考えられると思います。
確かに「アルゴリズムを秘密にしているから安全」理論ですが、わざわざクラッカーにトンネルを用意してあげる必要もないのも事実です。
# 結局「PC 起動パスワード」の設定位しか防衛手段はないとかなりそうです。
Re: (スコア:0)
>なんてのはデメリットが大きすぎじゃないでしょうか。
TPMは(適切に運用されていれば)PINやTPMそのもののパスワードを付与して運用できるので、
別にNTFSが公開されたからと言って問題になる性質の物ではありません。
>確かに「アルゴリズムを秘密にしているから安全」理論ですが、わざわざクラッカーにトンネルを用意してあげる必要もないのも事実です。
この理論の適用には幾つかの問題があります。
- CaptiveNTFSのようなNTFS
Re: (スコア:0)
ACL はセキュリティとして機能しませんという指摘ですから、
ポイントがずれてるとうのは納得がいかないです。
NTFS を設計した人たちもハードウェア自体は保護されている場合を前提としています。
Administrator 権限があれば「不明な ACL」(つまり他のコンピュータで作成された ACL) の削除や
ファイルの所有権の変更が可能なのはStealthさん自信が理解されている通りです。
ですから、物理的な盗難があった時点でどうにでもなるのです。
あ、泥棒は盗んだHDDを自分のパソコンに物理的に接続した場合に、
制限ユーザーでアクセスしなければならないRFC作ってくれるってことですか?(゚∀゚)
Re:NTFS (スコア:1)
ちょっと読み間違えていたようです。
BitLocker のようなソリューションであっても、本気でデータを狙ってる相手に (一太郎の穴を見つけて攻撃してくる人たちとかに) ハードごと取られちゃうと結局防止策になってないんじゃない? というのがあります。この辺りだと BIOS/HDD パスワードですら全力で突破してきそうです。そこらのライトな (?) 泥棒なら十分に効果は得られると思いますが。
まぁ、そこまで言いだすと「どうしようもねーよ」とか「そもそも盗まれるなよ」という話になってしまいますが。
なんという 4/1 RFC。
それはともかく、amd 使ってたら一般ユーザ権限でも ntfs-3g とかで自動的にマウントされてしまい、ユーザとしては一般ユーザのみの利用でアクセスしてませんか? ;)
Re:NTFS (スコア:1)
Re:NTFS (スコア:1)
そんなM$の製品でも、NTFSというFSの実装へのトレールがどのようになっているか。というのはちょっときになります。
だって、うちでは少なくともNTFSはWindows2000のお供としてよく動いて(クラッシュしたらext3みたいに記憶喪失じゃない様子ですし)いるようにおもえますし・・・
いちようNTFSはPOSIX準拠を謳っているFS実装ですし、どのくらい標準に忠実で、どのくらい拡張がされていて、どのくらいWindowsには不用だと切捨てられた仕様や、どのくらいインチキ実装があるのか興味深いとおもいます。
大槻昌弥(♀) http://www.ne.jp/asahi/pursuits/ootsuki/
Re: (スコア:0)
Re: (スコア:0)
物理ドライバに分かれていて、物理ドライバをサードパーティが作るために
APIが用意されていたら、公開されたAPIに入っているような気がします。
じゃないと、windowsが標準でサポートしていないハードウェアを使う
ドライブ(例えばOSリリース後に開発されたコントローラを使うRAIDなど)の
ドライバ開発時に、ファイルシステムの内部に直接手を入れるようなことが
必要になるでしょうから。
でも、そのAPIって、IDEのHD上でどのクラスタに何の情報がどういう順番で
書かれているかは分からないものですよね。
その書かれる位置などを決めているのは、IDEのドライブだったら、OSが
標準的に持っているIDEの物理ドライバですから。
ということで、お望みの情報は出てこないと思います。