特定のフォルダに対して制限をかける方法について

Question

あるアプリケーションが実行中は、そのアプリケーションが利用（参照）しているフォルダに対して、

  ・フォルダ名の変更

  ・フォルダ削除

  ・アクセス権の変更

が(Administrator権限のユーザであっても)行えないようにしたいのですが、何方か実現方法をご存じないでしょうか。

 

開発環境

  VS 2003 VC++

  (.NET Framework未使用)

 

実行環境

  Windows XP SP2

  Windows 2000 SP4

Answer 1

 

あるアプリケーションが実行中は、そのアプリケーションが利用（参照）しているフォルダに対して、   ・フォルダ名の変更   ・フォルダ削除   ・アクセス権の変更 が(Administrator権限のユーザであっても)行えないようにしたいのですが、何方か実現方法をご存じないでしょうか。   ACL をいくら設定したところで、Administrators group の member である限り、SeTakeOwnerPrivilege を所持していますのでいくらでも ACL は変更できます。 では、SeTakeOwnerPrivilege を与えなければ OK か？というとそうではなく、Administrators の member の場合、特権を自由に設定できてしまいます。   つまり、Administrators の member である限り不可能です。 ということで、administrators の member を使用させない方向で検討してください。

Answer 2

アクセス権の変更を抑止は、ちゃっぴさんが書いているように、アカウントに権限がある限り制御不可能ですが、フォルダであれば、そのフォルダにあるファイルを開きっぱなしにした状態であれば、削除はできなくなります。

#もちろん、削除できないのは開いているファイルとそのファイルがあるフォルダなので、それ以外のファイルは削除可能ですが。

 

確か名前の変更もできなかったはずですが、それは試してみないとわかりません。

 

Answer 3

ちゃっぴ様、とっちゃん様

 

ご回答いただきありがとうございます。

 

また、お返事が遅くなりまして申し訳ありません。

 

いただいた回答から、やはり、Administrator(Administratorsグループ含)

権限をもったユーザでログインすればどのような状態であろうとフォルダの

アクセス権が変更可能が出来てしまうということのようですね。

※私もとっちゃん様の回答いただいた方法も検討したのですが、

  アクセス権限変更抑止まで制限できないため、アクセス権限変更抑止まで

  含めた制限を行う方法がないかとご質問させていただきました。

 

なぜこのようなご質問をさせていただいたかというと、アプリケーションの

実行中にアプリケーションがシェアしているフォルダを他のプロセスが

操作することで見えなくなる（アクセスできなくなる）ことを防ぐことで、

存在チェック、アクセス権チェック等を軽減できないかということで、

ご質問させていただいた次第です。

 

やはり、フォルダを利用する都度、存在チェック、アクセス権チェックを

行う方法しかないのでしょうか。。。

Answer 4

HJOB さんからの引用

いただいた回答から、やはり、Administrator(Administratorsグループ含) 権限をもったユーザでログインすればどのような状態であろうとフォルダの アクセス権が変更可能が出来てしまうということのようですね。 ※私もとっちゃん様の回答いただいた方法も検討したのですが、   アクセス権限変更抑止まで制限できないため、アクセス権限変更抑止まで   含めた制限を行う方法がないかとご質問させていただきました。

完全な排他 lock してしまえば、その application 以外からはまったく扱えないと思います。

ただし、Adminstrators の member なら他の user の process も強制終了できちゃいますがね。

 

なぜこのようなご質問をさせていただいたかというと、アプリケーションの 実行中にアプリケーションがシェアしているフォルダを他のプロセスが 操作することで見えなくなる（アクセスできなくなる）ことを防ぐことで、 存在チェック、アクセス権チェック等を軽減できないかということで、 ご質問させていただいた次第です。   やはり、フォルダを利用する都度、存在チェック、アクセス権チェックを 行う方法しかないのでしょうか。。。

 

ではなく、例外処理で対応すべきでしょう。

Lock していない状態ではいつ変更されるかわからないため、確認したところで作業時には違う状態になっていることがありえます。

Answer 5

ユーザーの誤操作も含め、エラーチェックを軽減できないか？と言うことでしょうか？

 

であれば、やはりちゃっぴさんの言う通り、例外処理ないしは、エラーチェックでその場対処が必須です。

 

たとえ、起動時には意図した状態で存在していたとしても、実際に操作しようとしたタイミングでは意図していない状況になっているというのは常に発生しえます。

特に、ファイルシステムの操作の場合、ユーザーに落ち度が全くない(ほかのプロセスも含め、一切悪さしていない)としても、デバイスそのもののハードエラーが発生することだって確率的には０ではありません。

 

結局のところ、失敗してから、その理由に応じて対処するという方法以外に確実にリカバリできる方法はありません。

 

実際、ユーザーの環境によっては、なぜこのマシンは動いているの？と思うくらい不思議な状況で動いているという場合もありますから。

 

Answer 6

ちゃっぴ様、とっちゃん様

 

ちゃっぴ さんからの引用

HJOB さんからの引用    いただいた回答から、やはり、Administrator(Administratorsグループ含) 権限をもったユーザでログインすればどのような状態であろうとフォルダの アクセス権が変更可能が出来てしまうということのようですね。 ※私もとっちゃん様の回答いただいた方法も検討したのですが、   アクセス権限変更抑止まで制限できないため、アクセス権限変更抑止まで   含めた制限を行う方法がないかとご質問させていただきました。 完全な排他 lock してしまえば、その application 以外からはまったく扱えないと思います。 ただし、Adminstrators の member なら他の user の process も強制終了できちゃいますがね。     なぜこのようなご質問をさせていただいたかというと、アプリケーションの 実行中にアプリケーションがシェアしているフォルダを他のプロセスが 操作することで見えなくなる（アクセスできなくなる）ことを防ぐことで、 存在チェック、アクセス権チェック等を軽減できないかということで、 ご質問させていただいた次第です。   やはり、フォルダを利用する都度、存在チェック、アクセス権チェックを 行う方法しかないのでしょうか。。。   ではなく、例外処理で対応すべきでしょう。 Lock していない状態ではいつ変更されるかわからないため、確認したところで作業時には違う状態になっていることがありえます。

 

フォルダにおける完全な排他lockとはどのようすればできるのでしょうか？

「排他lock」というとことは、その間は他のプロセスから「排他lock中」のフォルダへは

ファイルの作成、書込み、読取りも含め一切受付けられなくなってしまいませんか？

 

また、例外処理（、および、エラーチェック）で対応すべきということに関しては、ご指摘のとおり処理しようとした時点でどのような状態（アプリ起動時やとっちゃんさんの仰るとおりH/W異常）になっているか不定であるため当然チェックは行いますが、一旦、特定の操作の制限が保証されるのであれば、それについてはチェック不要となるため制御の範囲が狭まると考えました。

Answer 7

HJOB さんからの引用

フォルダにおける完全な排他lockとはどのようすればできるのでしょうか？

 

こんな感じ。

Code Snippet

HANDLE hFile = CreateFile(_T("path")
                        , FILE_ALL_ACCESS
                        , 0
                        , NULL
                        , OPEN_EXISTING
                        , FILE_FLAG_BACKUP_SEMANTICS
                        , NULL);

 

HJOB さんからの引用

「排他lock」というとことは、その間は他のプロセスから「排他lock中」のフォルダへは ファイルの作成、書込み、読取りも含め一切受付けられなくなってしまいませんか？

 

その folder の ACL は残念ながら編集できちゃいますけど、配下は扱えないようですね。

SeChangeNotifyPrivilege があってもダメっぽいので。。。

 

HJOB さんからの引用

また、例外処理（、および、エラーチェック）で対応すべきということに関しては、ご指摘のとおり処理しようとした時点でどのような状態（アプリ起動時やとっちゃんさんの仰るとおりH/W異常）になっているか不定であるため当然チェックは行いますが、一旦、特定の操作の制限が保証されるのであれば、それについてはチェック不要となるため制御の範囲が狭まると考えました。

 

事前でも、事後でも check は必要ですよね。

もっとも今回の場合、事前に確認したところで lock でもしていない限り保障されないわけでして、意味が無いわけですが。。。

確かに事前 check は非常に重要な場合が多いんですが、それは外部から変更されないことが保障されている場合(たとえば private memory とか)のみ成立することです。

 

じゃあ、lock してやったらどうなるでしょう？使い勝手悪くなりますよね？

 

なので、このような場合には例外が発生するものを使っているのであれば、例外で受けてそれを適切に処理する。

例外が発生しないものを利用している場合には、戻り値とか GetLastError とかを使って必ず確認するというのが重要です。

 

[追記] private memory でも multi thread な application の場合には、lock しないとえらいことになります。[/追記]

Answer 8

遅くなりましたがご回答いただきありがとうございました。

 

確かにおっしゃるとおり、外部からはアクセス出来なくなるため

外部側は使い勝手は悪くなります。

当初は、排他にしてほしいという要望でしたが、普通の

例外処理で対応するようにしました。

 

大変参考になりましたｍ（＿＿）ｍ