20.05.2020 15:45
Programmierus 8 2000 Источник

КПДВ:Госуслуги


Уже более года все наши сотрудники работают только в опубликованных приложениях, а централизуем мы всё это через Parallels RAS. Есть у нас и автоматический механизм публикации ЭЦП: если авторизованный пользователь запускает сайт, допустим таможни, то предварительно в его HKCU пишется ЭЦП компании и запускается нужный плагин. Это отлично работает с КОНТУР, СБИС, КРИПТО-ПРО, но плагин от госуслуг (IFCPlugin) пришлось допиливать напильником, а к разработчикам остались вопросы…


Когда поступила заявка на установку очередного плагина, читающего ЭЦП, я не ожидал ничего сложного. Для работы с ЭЦП у нас выделен отдельный RDS-хост на котором уже стояло несколько плагинов и всё отлично работало. Я скачал плагин госуслуг с официального сайта и не мудрствуя лукаво запустил установку в машинном контексте из привилегированного шелла:


msiexec -i c:\pathtofile\mypackage.msi ALLUSERS=1

На первый взгляд, установка прошла успешно. В списке установленных программ на этом хосте появился «Плагин пользователя систем электронного правительства», под своей учетной записью я смог авторизоваться с помощью ЭЦП. Но у других пользователей плагин так и не заработал, будто и не был установлен.


Куда же ты запропастился?


Плагин госуслуг, в отличие от других аналогичных решений, никак не сообщает о своем присутствии пользователю. Нет иконки в трее, нет группы в стартовом меню, не нашел я его и в "Program Files". Т.к. под моей учеткой работала авторизация в Chrome, а она работает с помощью браузерного плагина, который, в свою очередь, должен иметь MessagingHost, я решил поискать этот процесс.


Каково же было мое удивление, когда я обнаружил этот процесс (ifc_chrome_host.exe) в собственной $Env:APPDATA! Иными словами, инсталлятор плагина, полностью игнорируя машинный контекст, поставил приложение внутрь моего профиля. Причем даже не в $Env:LOCALAPPDATA, а в подлежащую роумингу часть профиля. У нас включен роуминг аппдаты (на эту тему можно долго холливорить, но мы считаем, что в нашем случае — это правильно). Т.е. IFCPlugin установился в мой профиль, хранящийся на файловом сервере, куда только я имею доступ, но зарегистрировал себя и свои классы в машинном контексте на RDS-хосте. Вполне логично, что у пользователей плагина, по сути, не было.


Достаем напильник


Открываем старую добрую orca и смотрим на структуру директорий установщика IFCPlugin.msi:


MSI:Directory


TARGETDIR = AppDataFolder. Чем руководствовались разработчики я понять не смог. Заменяем на ProgramFiles64Folder или ProgramFilesFolder по вкусу.


Смотрим что с реестром:


MSI:Registry


Как видим, всё, кроме классов, прописывается в HKCU. Т.к. меня волновало функционирование лишь плагина для Google Chrome, то я изменил ветку только трем отмеченным параметрам на 2, что соответствует HKLM. Подозреваю, что для Firefox сработает аналогично.


Еще один напильник


Устанавливаю заново. Плагин ожидаемо появляется в $Env:ProgramFiles, но у пользователей, почему-то сразу падает процесс ifc_chrome_host.exe, хотя он уже запускается. Берем procmon и смотрим что ему не хватает.


Выясняется, что он пытается писать логи вот сюда:


$Env:ProgramFiles\Rostelecom\IFCPlugin\X.X.X.X\x32\LOGS

Пользователи, по умолчанию, разумеется, не имеют там доступа на запись. Исправляем.


Заключение


Работает. Что курили разработчики и зачем это было сделано именно так, осталось для меня загадкой.