可能使用提升的權限創建的日誌文件

Question

我有一個非常舊的應用程序，現在需要對Windows Server 2008友好。它是一個用作單例的用戶應用程序。它使用註冊表的HKLM部分來讀取和寫入配置，並創建日誌文件。

主要問題：如何使UAC的應用程序適合當前最佳實踐？

我最初的方法是運行應用程序不升級，如果配置需要更改用戶手動重新啓動它升高，重新配置，並重新啓動到非升高。問題是日誌文件可以創建爲高級，然後非高級應用程序無法寫入。可能的解決方法：

1. 不要在提升模式下做任何暗示寫入日誌文件的事情。但是如何檢測應用程序是否處於提升模式？
2. 即使在提升模式下也可以使用非提升權限創建日誌文件。怎麼樣？
3. 如果在打開現有日誌文件時訪問被拒絕，則嘗試創建另一個日誌文件。
4. 一直運行提升。

第一種選擇是迄今爲止最好看，但如何檢測海拔？也許還有其他的選擇？也許有一些完全不同的方法？如果可能的話，我不想過多地更改代碼。

Answer 1

最好的做法是重寫應用程序以使用每個用戶的存儲空間，除非您確實需要某個用戶保存的某些內容來影響框中的其他用戶。也就是說，答案「只有一個用戶，因此每個用戶和每臺機器都是相同的」被拒絕。在這種情況下，整個應用程序始終運行不升級，並具有防止虛擬化的清單。

下一個最佳實踐是對應用程序進行分區。寫入HKLM的代碼在單獨的exe文件中，並且具有請求提升的清單。 UI有一些警告（一個按鈕或菜單項上的屏蔽），用戶在該位置運行此代碼。單獨的進程與ShellExecute一起啓動，它尊重清單。用戶的體驗是大多數時候應用程序運行時沒有提升，有時它的一部分似乎提升然後降低。這就是它看起來像但這實際上是不可能的 - 一個EXE要麼升高，要麼不升高。你用兩個exes達到效果。

第三件好事是將日誌移動到某個地方，無論您是否升高，並在需要時訓練用戶手動升起。我認爲這不是一個好的解決方案，但是比培訓他們每次在不同地方手動提升和寫入日誌文件要好。我猜你寫在「當前目錄」下，它本身在Program Files下，並且你沒有清單。然後，當不提升你的應用程序將寫在虛擬商店。如果用戶需要查找日誌文件，這真的不好。寫入不同的文件夾 - AppData下的東西會很好。該位置不會被虛擬化。

檢測您是否被提升的最簡單方法是使用IsInRole查看用戶是否爲管理員。作爲一個小測試將證明，即使管理員用戶得到false當應用程序沒有提升，甚至非管理員誰提高OTS提示將返回true返回。

Answer 2

UAC是一個相當戲劇性的變化;在事實充滿危險之後，試圖迫使你的申請適合它。將註冊表和日誌文件位置從機器區域更改爲用戶區域不是更容易嗎？例如HKCU和CSIDL_APPDATA。如果這不適合你，那麼用戶只需要提升你的應用程序;你可以指定一個requireAdministrator清單。