Здравствуйте, c-smile, Вы писали:
CS>Есть: процесс который исполняется с правами администратора (так надо). CS>Нужно: исполнить GUI (показать диалог) но с правами залогиненного юзера. CS>Гипотеза: создать GUI thread с соотв. правами и в нем уже запутстить тот диалог. CS>Как получить ACL SecurityDescriptor, и т.д. залогиненного пользователя? CS>Скажите нужные слова пожалуйста для поиска. Тема не моя — плаваю.
ACL здесь не причем.
Поток нужно имперсонировать пользователем (например, ImpersonateLoggedOnUser).
Для этого нужно его токен.
Токен можно получить явно, зная логин/пароль (LogonUser).
Или взять у какого-нибудь процесса, который уже работает от имени этого пользователя (OpenProcessToken).
Какой-нибудь explorer.exe...
CS>Гипотеза: создать GUI thread с соотв. правами и в нем уже запутстить тот диалог.
Если это делается из соображений безопасности — то отметайте эту гипотезу. Впрочем если не для безопасности — тоже отметайте.
Перечислять все частные причины — честно говоря долго, а общие — вот тут описаны.
Вобщем, запускайте отдельный процесс под нужным юзером и показывайте из него.
А где взять токен юзера — вопрос совершенно нетривиальный. Решений много, но у всех свои ограничения и чтоб предложить конкретное мало исходных данных. Варианты:
1) Найти обычный процесс-шелл explorer.exe (например по его окну или тупо перебрав список процессов) и стыбзить у него токен. Проблема в том что обычного процесса-шелла может вдруг не оказаться, мало ли какая у юзера. Вобщем довольно топорное решение. Но — популярное. Я тоже так делал 10 лет назад (дада, тогда когда UAC'а еще не было, а большинство вендодевелоперов свято верили что юзер в винде — всегда админ).
2) WTSQueryUserToken — если ваш админский процесс имеет SE_TCB_NAME привилегию. Обычно ее имеют только сервисы, да и то не все. Конечно будучи админом ее можно присобачить себе, но это геммор и еще больший топор-костыль.
3) Если же ваш процесс — не сервис, то очевидно вначале его запускает обычный юзер, но (включая телепатию) у него там в манифесте прописано "Хачу хача админа", в результате чего юзер видит UAC, и — процесс запускается уже совсем под другим юзером (админом). (Или не запускается, что видимо не наш кейс). В такой ситуации лично я бы убрал это из манифеста, гуевый процесс бы просто запускался под текущим юзером, а админские таски бы исполнялись в отдельном процессе, который бы запускал гуевый процесс через ShellExecute(.."runas"..).
Как много веселых ребят, и все делают велосипед...
Здравствуйте, c-smile, Вы писали:
CS>Есть: процесс который исполняется с правами администратора (так надо). CS>Нужно: исполнить GUI (показать диалог) но с правами залогиненного юзера.
Будет работать, даже если explorer.exe не запущен.
У нас такой финт используется во время деинсталляции одной программы, когда
требуется запустить один компонент с правами обычного пользователя (XP-Win8.1).
Но есть большой минус: в Path нельзя передавать аргументы командной строки.
Способ №2.
Найти explorer.exe — GetShellWindow, GetWindowThreadProcessId, OpenProcess.
Взять его access token — OpenProcessToken, сделать дубликат — DuplicateTokenEx.
С этим токеном запустить нужный процесс (возможно, с аргументами) через
CreateProcessWithToken (CreateProcessAsUser не будет работать, насколько я помню).
Если explorer.exe не запущен, GetShellWindow вернет NULL.
Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
Придется опять велосипед изобретать. Ну да мы привычные...
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, c-smile, Вы писали: CS>Всем ответившим — спасибо. CS>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких. CS>Придется опять велосипед изобретать. Ну да мы привычные...
Сорри, если мой коммент не совсем в тему. Я никогда не использовал Sciter. Но если вы спрашиваете в разрезе того, использовать ли одновременно с диалогами, нарисованными в Sciter, еще и нативные виндовые диалоги, я бы с позиций тестирования предпочел, чтобы все было однообразно. У меня была аналогичная ситуация с Qt, когда для отрытия файлов использовались нативные диалоги, созданные с помощью QFileDialog::getOpenFileName(), а остальные диалоги были Qt-шные. Нативные-то нативные, а протестировать все равно надо было. А в Qt стандартные функции поиска объектов по идентификатору типа QObject::findChildren() не работают для нативных элементов управления. Пришлось обходные пути искать. Так что лучше все единообразно.
Re[2]: GUI/ACL вопрос.
От:
Аноним
Дата:
04.08.14 21:06
Оценка:
CS>Всем ответившим — спасибо.
CS>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких. CS>Придется опять велосипед изобретать. Ну да мы привычные...
Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.
Здравствуйте, Аноним, Вы писали:
CS>>Всем ответившим — спасибо.
CS>>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких. CS>>Придется опять велосипед изобретать. Ну да мы привычные...
А>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.
Люди которым я доверяю в этом вопросе сказли что для них они (дыры) критические. Попросили лисапет.
Re[4]: GUI/ACL вопрос.
От:
Аноним
Дата:
06.08.14 21:41
Оценка:
CS>>>Всем ответившим — спасибо.
CS>>>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких. CS>>>Придется опять велосипед изобретать. Ну да мы привычные...
А>>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.
CS>Люди которым я доверяю в этом вопросе сказли что для них они (дыры) критические. Попросили лисапет.
Ну я ж не просто так спрашиваю. Если люди имеют отношение к AV, то для них должно быть очевидно, что бОльшую часть дыр компенсирует самозащита, даже самая убогая. А меньшую — запуск UI под ограниченным пользователем. В общем, все-таки хотелось бы конкретики.
Здравствуйте, Аноним, Вы писали:
А>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.
может имеется ввиду тот факт, что при вызове стандартного диалога открытия файла, поднимается проводник — по сути, это он и есть, вдобавок куча нацепленноло на него "гражданского" софта, который придает только унылости (особенно, в отладке. поймут те, кто отлаживался с полными символами)
А>>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.
RW>может имеется ввиду тот факт, что при вызове стандартного диалога открытия файла, поднимается проводник — по сути, это он и есть, вдобавок куча нацепленноло на него "гражданского" софта, который придает только унылости (особенно, в отладке. поймут те, кто отлаживался с полными символами)
Ну тут речь идет о UI процессе, так что загрузки левых модулей митигируются обычной самозащитой, а остальное... Интересно, что предлагаются в таком случае насчет http://www.mista.nu/research/mandt-win32k-slides.pdf. Не использовать win32k?
Я к тому, что надо все-таки понимать, о чем идет речь и выбирать адекватные инструменты.