search

dasMulli / dotnet-win32-service

Helper classes to set up and run as windows services directly on .net core. A ServiceBase alternative.
MIT License
451 stars 57 forks source link

Stopping and starting a service without admin rights #81

Open TomWouters opened 5 years ago

TomWouters commented 5 years ago

Hello Daniel,

I've succesfully used your windows service library in a number of applications running under net core, over Peter Kottas library. So thanks a lot for the nice integratable solution.

I just have one issue.

I have a service, installed as an admin user (necessary for the application). The current logged in user is a normal user, with no option to elevate rights. For updates, new files are downloaded, the service is stopped, files are renamed, and the service is started.

What I'm noticing is that for starting and stopping a service, installed/running under an admin account, elevated rights are necessary.

Is there a way we can call the install command, so that start and stop rights are granted to all users?

I've found a similar question/response on stack overflow, where there is an instructionset on how to do it using windows, but it would be perfect if those rights could be set using the install command.

Link: https://stackoverflow.com/questions/10850595/windows-service-start-and-stop-without-admin-privileges

If this is implemented in the dasMulli library, I'll pick it up with Peter (or fork the library), so that it can also be wrapped there.

dasMulli commented 5 years ago

So i've been thinking about this for a bit. A few key points:

  1. This is the first time i've heard about this - personally I try to make sure all deployments are properly automated and the agents / users have the rights they need. Other services like the azure devops agents are even able to update themselves by starting an update process that inherits their privileges.
  2. Security configuration is a dangerous thing, even if implemented correctly. I'm not sure if i want to maintain code in this package that directly uses Windows functions to mess with security configuration (in this case SetNamedSecurityInfoW and friends). That doesn't mean that i'm not open to it, but i don't want to do it for a feature that i haven't gotten many requests for and don't need myself. Plus there are also other ways to do it - the API to register/unregister services only exists b/c there was/is no ServiceInstaller for .NET Core and shelling out to sc.exe is messy. Plus i figured it might help with other code (installers for example) that needs to configure services - turns out i'm right and some users even extracted out all this code without even needing the ServiceBase alternative.
  3. subinacl.exe is a nice commandline that can do what you want and you could call it after registering a service (for which you need privileges anyway). Did you try this already? I suppose you may need some command line escaping though.

Summing up: I'm quite reluctant to add this as a feature.