1

特権の昇格は、ほとんどの開発者が単にそれを持っていないため、ほとんどの開発者が苦労しているようです。私はそうしますが、大規模なバックグラウンド ワーカー ルーチンと戦っており、それを使用するクラスに対してコードをローカルに保とうとしています。「RunWorkerCompleted」ハンドラー メソッド内で完了するとバックグラウンド ワーカーが作成するコードと参照の量を考えると、これを実行可能な代替手段として受け入れるのは難しいことがわかります。

宿題 1:

宿題 2:

宿題 3:

バックグラウンド ワーカーによる MainForm クラスへの依存度が高すぎるため、ソリューション全体を「管理者」権限を持つ別のプロセスに出荷することを検討できません。これには、あまりにも多くの切り刻みと変更が含まれます。

オメガコーダー：

70-536 試験のために CAS を読み、上記の例のほとんどの用語を認識しましたが、それがどのように、なぜ機能するのかわかりませんでした。「ManagersOnly」メソッドに権限が付与されている理由を誰か説明してもらえますか? PrincipalPolicy が WindowsPrincipal に変更されると、次の 2 つの手順は、通常のオブジェクト インスタンス化ステートメントのように見えます。

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal, IPrincipal, IIdentity);

明らかに、そのようなオーバーロードは存在しませんが、そのオーバーロードが何をするかは非常に明確です。

質問 1: OmegaCoders の例はどのようにこの効果を達成していますか? 私のユーザーは「BUILTIN\Administrators」グループの一部であるため、間違いなく機能するためです。私は文学に基づいた答えを探しているので、あなたが感じる限り詳細に進んでください。

更新 1:

質問 2: PrincipalPolicy を以前の状態に戻すにはどうすればよいですか ... メソッドが返されたら、PrincipalPolicy を 'WindowsPrincipal' に設定する必要はありませんか??? そのため、アプリケーションは、意図したとおりに権限の低いユーザーとして実行し続けることができます。

質問 3:「ManagersOnly」メソッドが戻ると、権限は破棄されますか? メソッドの寿命までスコープが設定されていますか?

System.AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.NoPrincipal);

*更新2：*

私のWin7 Pro開発マシンでは何でもテストして実行できますが、単純なWin7 Homeラップトップでいくつかのコードをテストしようとすると、アクセス許可が拒否されていることがわかりました。プリンシパルポリシーを 'WindowsPrincipal' に変更しても、すべての Vista および Win7 ユーザーに対して機能するとは限りません。多くのユーザーは管理者ユーザー グループの一部でさえありません。したがって、このオプションは役に立ちません... この小さなラップトップに座っていると、私が必要とするソリューションではないことが明らかになります。

以前の質問は無視してください - 私自身の研究では、それらは実現不可能です。

質問 4: コードでプログラムおよび一時的に管理者になりすますにはどうすればよいですか?

4

1 に答える 1

1

短い答えはノーです。

ユーザーが適切なグループに属していない場合、CASがRBSを補完するため、私が行ってきたすべての掘り下げラウンドの後、メソッドのアクセス許可を昇格させるプログラム的な方法はないようです。次に、rbs がユーザーがグループの一部ではないことを cas に通知するため、管理者権限にアクセスしても意味がないため、要求はバウンスされ、許可が拒否されます。例外が発生します。

ユーザーが必要なグループ、つまり管理者の一部である場合、Domains PrincipalPolicy を変更すると一時的な解決策が得られますが、単に管理者ユーザー グループの一部ではないユーザーには対応できません。上記のソリューションが崩壊する場所です。

長い答えは、問題が発生しやすいコードを小さな別の .exe ファイルに送り、それを個別に実行することです。

于 2010-08-07T17:55:48.367 に答える