Несколько сервисов из одного исполняемого файла

Question

Я написал небольшой сервис (обычный Win32), и я хотел бы знать, возможно ли запустить его несколько экземпляров, когда в систему вошли несколько пользователей.

По сути, предположим, что у нас есть UserA и UserB для UserA, служба будет входить в систему как «домен \ UserA», а для UserB служба будет входить в систему как «домен \ UserB» - это, конечно, из того же исполняемого файла , Я могу динамически изменить вход в систему с помощью функции ChangeServiceConfig (), но, похоже, она меняет ее для всей системы, хотя я бы хотел, чтобы у каждого пользователя была своя собственная копия службы, работающей только для него.

Заранее спасибо за любые указатели.

Answer 1

Службы Win32 предназначены для всей системы и запускаются до того, как любой пользователь вошел в систему. Если вы хотите, чтобы что-то запускалось для каждого пользователя, вероятно, лучше спроектировать его как обычное приложение и запускать из группа запуска пользователя.

Answer 2

Вы хотите, чтобы это выполнялось постоянно, поэтому вам нужна служба.

Вы хотите, чтобы что-то отслеживало каждого пользователя, поэтому вы хотите, чтобы приложение запускалось в сеансе пользователя и связывалось со службой (используя именованные каналы или DCOM или любое другое, что соответствует вашим требованиям).

Answer 3

Вам не нужно несколько экземпляров вашего сервиса. Из описания вашей проблемы видно, что вам нужна одна служба, которая может выдавать себя за пользователей и выполнять задания от их имени.

Вы можете сделать это путем реализации COM-объекта, размещенного в службе. Ваше клиентское приложение (которое запускает конечный пользователь) будет вызывать CoCreateInstanceEx для вашего CLSID. Это приведет к созданию нового экземпляра вашего COM-объекта в вашем сервисе. Затем приложение может использовать метод на одном из ваших интерфейсов для передачи собранных учетных данных пользователя в COM-объект (хотя я бы с осторожностью отнесся к сбору учетных данных и вместо этого посмотрел бы, могу ли я вместо этого передать маркер пользователя). COM-объект, который выполняется в контексте службы, может затем вызвать LogonUser (), чтобы войти в систему пользователя и выдать себя за него, чтобы он мог делать что угодно от ее имени (например, находить локальную папку appdata пользователя :-)). В других ответах есть хорошие ссылки на выдачу себя за пользователей, использующих учетные данные или токен.

Если вы чувствуете себя комфортно с COM, я бы посоветовал вам создавать ваши объекты как многопоточные (живущие в MTA), чтобы их выполнение не сериализовалось COM. Если нет, то для вас будет достаточно однопоточной модели по умолчанию.

Мастер Visual Studio ATL может создать каркас COM-объекта, живущего в службе. Вы также можете прочитать о реализации Windows Service с ATL здесь: http://msdn.microsoft.com/en-us/library/74y2334x(VS.80).aspx

Если вы вообще не знаете COM, вы можете использовать другие каналы связи для передачи учетных данных вашей службе.

В любом случае, как только ваша служба получит учетные данные, вся работа от имени пользователя должна будет выполняться в фоновом потоке, чтобы не блокировать приложение, работающее от имени пользователя.

Answer 4

Процесс Windows может выполняться только с правами одного пользователя одновременно. Это относится к услугам и другим процессам. При наличии достаточных привилегий можно «переключаться» между разными пользователями с помощью олицетворения. Наиболее распространенный шаблон того, что вы пытаетесь сделать, - это иметь один экземпляр привилегированной службы, которая регистрируется для входа / выхода из событий и соответственно создает дочерние процессы, каждый из которых выдает себя за зарегистрированного пользователя. Шаблон также упростит пользовательский интерфейс, поскольку каждый процесс выполняется на рабочем столе каждого отдельного пользователя, как если бы это было обычное приложение.

Если вы сохраняете код привилегированной службы как можно более простым, этот шаблон имеет дополнительное преимущество, заключающееся в том, что вы минимизируете поверхность атаки своего кода. Если пользователь обнаруживает проблему безопасности на стороне «Запуск от имени пользователя» вашей службы, это не проблема, а проблемы безопасности в привилегированных службах могут привести к повышению привилегий. Фактически, до того, как привилегированные службы Vista, реализующие цикл обработки сообщений Windows, были уязвимы для типа атаки, называемой Shatter attack , о которой вам следует знать, учитывая то, что вы пытаетесь сделать.

Answer 5

Возможна работа с разными аккаунтами. На самом деле это обычное дело. См. Svchost.exe, который реализует множество служб ОС.

Я просто не понимаю, как вы определяете, какие учетные записи. В большой компании настроено много ПК, чтобы его могли использовать все более 100 000 сотрудников. Вы не хотите запускать службу как вошедшие в систему пользователи, а также не хотите запускать ее для всех 100 000 пользователей. Так по каким счетам я должен спросить?

Answer 6

Вы можете создать приложение-службу и не-сервисное (обычное) приложение и заставить их связываться через IPC (Mapped File, Pipes, MailSolts ... вы называете это).

Таким образом, вы решаете все проблемы.

ПРИМЕЧАНИЕ. Одно и то же приложение может вести себя по-разному - при запуске как процесс и при запуске пользователем, но, в конце концов, это одно и то же, у вас все еще есть 2 приложения (независимо от того, есть ли у вас только один исполняемый файл).

Answer 7

Звучит так, как будто у вас на самом деле есть два разных, противоречивых требования, касающихся времени и личности.

1. Запуск от имени каждого зарегистрированного пользователя
2. Запускать автоматически, даже если ни один пользователь не вошел в систему.

Нет способа сделать это тривиально, вместо этого рассмотрите возможность обернуть вашу программу в службу; программа будет запускаться нормально при запуске для каждого пользователя (через папку запуска или taskcheduler), и в дополнение создает службу для запуска вашего приложения как системный пользователь (или любой другой пользователь, которого вы определили).
Поскольку вам также необходимо (вы упомянули об этом в комментариях), чтобы приложение продолжало работать в качестве конечного пользователя даже после того, как он вышел из системы, вы можете попросить службу управлять этим процессом самостоятельно.

ОДНАКО это может быть не самой лучшей идеей, поскольку пользователь все еще эффективно вошел в систему. Это может иметь множество побочных эффектов, включая безопасность, производительность (слишком много пользователей вошли в систему одновременно ...) и т. Д.

Answer 8

Вы, вероятно, ищете выдавать себя за пользователей. Проверьте некоторые ссылки, которые я нашел с помощью быстрого поиска Google здесь:

• Статья MSDN о WindowsIdentity.Impersonate
• Статья блога .Net Security

Answer 9

Да, это звучит близко (я отвечаю на комментарий Грега, но комментарии слишком короткие, чтобы соответствовать моему ответу).

Я не знаю заранее списка пользователей, но есть приложение для управления графическим интерфейсом, которое будет использоваться для ввода пар имя пользователя / пароль для каждого пользователя. Таким образом, userA будет входить в систему, запускать приложение, вводить свои учетные данные и сервис будет использовать это. В то же время (после того, как пользователь А вышел из системы, но служба все еще работает с учетными данными пользователя А), пользователь Б входит в систему, использует приложение, и другая копия службы запускается, как вошедшая в систему пользователя В Таким образом, одновременно работают службы userA и userB.

Это возможно?

Answer 10

Возможно ли, чтобы служба создала дочерние процессы, которые затем принимают учетные данные пользователя (или запускаются с ними)? Таким образом, вы по-прежнему ограничены одним экземпляром службы, но он может выполнять свои задания для каждого пользователя. IIRC служба планировщика заданий Windows делает это.