Per-user Windows Service
-
I - as a user - am running a daemon that I want to provide some service to other applications that I am running. Some of my applications are also using a library that interfaces with this daemon. Currently I'm using WCF via named pipes so all the plumbing is taken care of for me, but this solution seems to fall apart whenever another user logs onto the machine and also tries to start this daemon. Is there any way for both of our services to co-exist peacefully? Specifically, how can I allow multiple users to run a daemon concurrently (limited to one daemon per user) while - ensuring that a library running under user A's account will try to connect *only* to the daemon also running under user A's account, and - ensuring that the daemon running under user A's account will allow connections *only* from applications running under user A's account. I was thinking of creating a uniquely named pipe that derives from the user's SID, but this seems more like a hack than a solution and I think it would be quite fragile. I also wouldn't know how to limit connections to only the current user. If I'm going about this in the wrong way, that would also be nice to know. Thanks for any insight you guys and gals are able to provide! :D
-
I - as a user - am running a daemon that I want to provide some service to other applications that I am running. Some of my applications are also using a library that interfaces with this daemon. Currently I'm using WCF via named pipes so all the plumbing is taken care of for me, but this solution seems to fall apart whenever another user logs onto the machine and also tries to start this daemon. Is there any way for both of our services to co-exist peacefully? Specifically, how can I allow multiple users to run a daemon concurrently (limited to one daemon per user) while - ensuring that a library running under user A's account will try to connect *only* to the daemon also running under user A's account, and - ensuring that the daemon running under user A's account will allow connections *only* from applications running under user A's account. I was thinking of creating a uniquely named pipe that derives from the user's SID, but this seems more like a hack than a solution and I think it would be quite fragile. I also wouldn't know how to limit connections to only the current user. If I'm going about this in the wrong way, that would also be nice to know. Thanks for any insight you guys and gals are able to provide! :D
Windows services are per-machine, not per-user. One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service. The client piece runs per-user and is what the user would interact with, but it wouldn't be a service. It could be a task-tray application (one that only runs in the system notification area).
----------------------------- In just two days, tomorrow will be yesterday.
-
Windows services are per-machine, not per-user. One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service. The client piece runs per-user and is what the user would interact with, but it wouldn't be a service. It could be a task-tray application (one that only runs in the system notification area).
----------------------------- In just two days, tomorrow will be yesterday.
Scott Dorman wrote:
Windows services are per-machine, not per-user.
Right. I was considering just adding a daemon executable to the Startup path of whichever user installed the application.
Scott Dorman wrote:
One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service.
Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts. In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information. The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system. Hopefully this clarified things a bit. Again, thanks for your insight! :)
-
Scott Dorman wrote:
Windows services are per-machine, not per-user.
Right. I was considering just adding a daemon executable to the Startup path of whichever user installed the application.
Scott Dorman wrote:
One way to accomplish what you are doing is to have a service that does all of the work and then a client-side piece that communicates to the service.
Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts. In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information. The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system. Hopefully this clarified things a bit. Again, thanks for your insight! :)
Vega02 wrote:
I was considering just adding a daemon executable to the Startup path of whichever user installed the application.
Yes, that would be a good approach.
Vega02 wrote:
Ideally the user could install and run this application without requiring administrator privileges. Also, I want to minimize as much as possible the possibility of cross-communication between clients and daemons running under different user accounts.
Running the client piece without admin privs should be relatively simple. Installing without them might cause an issue on Vista.
Vega02 wrote:
In reality what I have going on is that the client is performing all the work. The client just needs to query the daemon for some state before work can commence, and it needs to tell the daemon how to update the state when the work is complete. When the next client queries the state, the daemon can respond with the updated information.
It sounds like the service is really just being used as state management.
Vega02 wrote:
The problem with a system-wide service is that the daemon can be used quite broadly, and the client might update the state with some private information. If the daemon is used as a day planner, for example, the client might add a personal appointment to the database. This isn't information that should be accessible to any other user of the system.
I'm not sure why this would be an issue. If the service is designed right and provides some sort of authentication mechanism between itself and it's clients, client A should never be able to see data from client B. Given the scenario you described, the underlying data store would need to be protected as well.
----------------------------- In just two days, tomorrow will be yesterday.