Какие части.NET требуют, чтобы административные привилегии были выполнены?
Какие части платформы требуют, чтобы пользователь был больше, чем Типичный Пользователь? Причина, которую я спрашиваю, состоит в том, потому что я пытаюсь составить список возможных проблем с нашими существующими приложениями при миграции на Windows 7.
Теперь, я могу думать о нескольких вещах сам:
- Запись в Eventlog
- Запись в Ключи реестра за пределами объема Current_User
- Получение Переменной среды
- и т.д...
Я действительно хотел бы больше полного списка, и до сих пор я не столкнулся с достойным ресурсом, в котором перечислен весь этот материал.
Обратите внимание, что я не ищу способы поднять полномочия для существующих приложений (который может быть сделан при помощи декларации), я просто определяю действия в коде, который мог бы вызвать проблемы.
9 ответов
Ну, ваши примеры на самом деле не имеют ничего общего с Windows 7 или .NET. На самом деле они уже были частью требований логотипа "Designed for Windows NT 4.0". Если вы написали свое приложение таким образом, что неадминистративные пользователи смогли запустить его на NT, Win2k или XP, оно будет прекрасно работать и на Vista/Win7.
Есть еще один распространенный подводный камень, когда вы запускаете свое программное обеспечение на системах x64 (однако это тоже не относится к Win7, а справедливо, например, для Win2003 Server x64 или Win XP x64): Если вы работаете с родным 32-битным кодом (например, вызовы родной DLL или COM interop с in-process компонентом), убедитесь, что в настройках проекта Visual Studio вы выбрали "x86" в качестве целевой платформы вместо "Any CPU". В противном случае ваше приложение будет работать как 64-битный процесс, а вы не можете смешивать 32- и 64-битный код в одном процессе, поэтому вы столкнетесь с ошибками.
И конечно, как это всегда было лучшей практикой, используйте Environment.GetSpecialFolders вместо жестко закодированных путей.
Одно из мест, где можно получить частичный список, - это заглянуть в «Редактор локальной групповой политики», где вы можете проверить, какие права на вход и привилегии назначены только администраторам по умолчанию.
Думая об этом как о «Что вызывает библиотека», вы ошибетесь. Подумайте обо всем, что записывает в файл. Если этот файл находится в Program Files (среди прочего), вам нужны права администратора. Если он находится в AppData, вы этого не сделаете. Тот же вызов библиотеки, разные результаты. То же самое и для записи в реестр - HKLM вам нужен админ, HKCU - нет. Запись в журнал событий - это нормально, но создание источника событий - нет. И так далее. Дело не в том, какой метод вы вызываете, а в параметрах (например, пути), которые вы ему передаете.
Вы можете использовать проверки Luapriv из Application Verifier , чтобы помочь вам найти проблемы. Также вам поможет стандартный пользовательский анализатор .
Я не верю, что получение переменных среды требует повышения привилегии. По крайней мере, я никогда не сталкивался с этим, действительно ли есть случаи, когда это правда?
Если я правильно понимаю ваш вопрос, Visual Studio может рассчитать его для вас ...
Просто перейдите в свойства вашего проекта, нажмите Безопасность и установите флажок «Включить параметры безопасности ClickOnce». Установите переключатель «Это приложение с частичным доверием», а затем нажмите кнопку «Рассчитать разрешения».
VS поставит галочку рядом с каждым разрешением, например IO, Registry и т. Д., Которые требуются вашему приложению ...
Именованные каналы могут вызывать проблемы. Обычно это не проблема, но теперь использование именованных каналов увеличивается, поскольку WCF изначально поддерживает их для транспорта IPC.
Ничто в среде .Net не требует прав администратора. Все, что связано с безопасностью на уровне пользователя, контролируется ОС, и требуются ли права администратора, зависит от конфигурации ОС. Таким образом, каркас не может определить, требуется ли повышение уровня.
Вы должны думать не о том, «Что в инфраструктуре .Net требует повышения прав?», А о том, «Какие функции ОС использует мое приложение, которые требуют повышения прав администратора в конфигурации по умолчанию». И, как сказал @Marcus, требования к логотипу «Разработано для Windows NT 4.0» - очень хорошая отправная точка для определения того, каких функций ОС следует избегать вашему приложению, если оно предназначено для работы в качестве обычного пользователя.
Я серьезно сомневаюсь, что есть способ получить полный список вызовов .NET, требующих повышения привилегий.
Кстати, запись в журнал событий не требует повышения прав, однако создание источника журнала событий требует повышения.
Лучший способ узнать, в каких частях вашего кода есть проблемы, - это протестировать на Win7 и посмотреть, какие из них ломаются, причем не изящно, но эффективно. Если вы хотите создать оценку времени для этой задачи, вам, возможно, придется потратить день или два на взлом вашего приложения: запустить на Win7, посмотреть, какие поломки, отметить это, прокомментировать / избежать / отключить этот раздел и повторить пока вы не решите, что у вас достаточно списка вещей, которые нужно решить.