Есть: процесс который исполняется с правами администратора (так надо).
Нужно: исполнить GUI (показать диалог) но с правами залогиненного юзера.

Гипотеза: создать GUI thread с соотв. правами и в нем уже запутстить тот диалог.

Как получить ACL SecurityDescriptor, и т.д. залогиненного пользователя?

Скажите нужные слова пожалуйста для поиска. Тема не моя — плаваю.

Здравствуйте, 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 (показать диалог) но с правами залогиненного юзера.

Из относительно простых способов:

ShellExecuteW(NULL, L"open", L"explorer.exe", Path, NULL, SW_SHOWNORMAL);

Path — полный путь к exe (возможно, в кавычках).

Будет работать, даже если explorer.exe не запущен.
У нас такой финт используется во время деинсталляции одной программы, когда
требуется запустить один компонент с правами обычного пользователя (XP-Win8.1).
Но есть большой минус: в Path нельзя передавать аргументы командной строки.

Способ №2.

Найти explorer.exe — GetShellWindow, GetWindowThreadProcessId, OpenProcess.
Взять его access token — OpenProcessToken, сделать дубликат — DuplicateTokenEx.
С этим токеном запустить нужный процесс (возможно, с аргументами) через
CreateProcessWithToken (CreateProcessAsUser не будет работать, насколько я помню).
Если explorer.exe не запущен, GetShellWindow вернет NULL.

Здравствуйте, c-smile, Вы писали:

Всем ответившим — спасибо.

Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
Придется опять велосипед изобретать. Ну да мы привычные...

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, c-smile, Вы писали:
CS>Всем ответившим — спасибо.
CS>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
CS>Придется опять велосипед изобретать. Ну да мы привычные...

Сорри, если мой коммент не совсем в тему. Я никогда не использовал Sciter. Но если вы спрашиваете в разрезе того, использовать ли одновременно с диалогами, нарисованными в Sciter, еще и нативные виндовые диалоги, я бы с позиций тестирования предпочел, чтобы все было однообразно. У меня была аналогичная ситуация с Qt, когда для отрытия файлов использовались нативные диалоги, созданные с помощью QFileDialog::getOpenFileName(), а остальные диалоги были Qt-шные. Нативные-то нативные, а протестировать все равно надо было. А в Qt стандартные функции поиска объектов по идентификатору типа QObject::findChildren() не работают для нативных элементов управления. Пришлось обходные пути искать. Так что лучше все единообразно.

CS>Всем ответившим — спасибо.

CS>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
CS>Придется опять велосипед изобретать. Ну да мы привычные...

Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.

Здравствуйте, Аноним, Вы писали:

CS>>Всем ответившим — спасибо.

CS>>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
CS>>Придется опять велосипед изобретать. Ну да мы привычные...

А>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.

Люди которым я доверяю в этом вопросе сказли что для них они (дыры) критические. Попросили лисапет.

CS>>>Всем ответившим — спасибо.

CS>>>Вопрос был в том делать или не делать свой fileopen dialog в котором (Windows) как оказалось куча дыр всяких.
CS>>>Придется опять велосипед изобретать. Ну да мы привычные...

А>>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.

CS>Люди которым я доверяю в этом вопросе сказли что для них они (дыры) критические. Попросили лисапет.

Ну я ж не просто так спрашиваю. Если люди имеют отношение к AV, то для них должно быть очевидно, что бОльшую часть дыр компенсирует самозащита, даже самая убогая. А меньшую — запуск UI под ограниченным пользователем. В общем, все-таки хотелось бы конкретики.

Здравствуйте, Аноним, Вы писали:

А>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.

может имеется ввиду тот факт, что при вызове стандартного диалога открытия файла, поднимается проводник — по сути, это он и есть, вдобавок куча нацепленноло на него "гражданского" софта, который придает только унылости (особенно, в отладке. поймут те, кто отлаживался с полными символами)

А>>Можно подробности по поводу дыр? Насколько я помню, они все митигируемые. А вот делать свой диалог — на мой вкус, это сильно нехорошо, т.к. это достаточно сильно интегрированная часть системы и внешний вид сильно специфичен для оси.

RW>может имеется ввиду тот факт, что при вызове стандартного диалога открытия файла, поднимается проводник — по сути, это он и есть, вдобавок куча нацепленноло на него "гражданского" софта, который придает только унылости (особенно, в отладке. поймут те, кто отлаживался с полными символами)

Ну тут речь идет о UI процессе, так что загрузки левых модулей митигируются обычной самозащитой, а остальное... Интересно, что предлагаются в таком случае насчет http://www.mista.nu/research/mandt-win32k-slides.pdf. Не использовать win32k?
Я к тому, что надо все-таки понимать, о чем идет речь и выбирать адекватные инструменты.