There is a UAC issue on installing a service, in that if you try and use the --install command while logged in as a user that does not have the privilege to install services, it will (properly) fail. So that is working as it should - in our testing here we use that command during our installation process, which is running with elevated privileges, so it works at that time, as it should.
As for normal use, I have the broker by default install itself under the LocalSystem account, which IIRC is the recommended account for services, and this account has reduced privileges on later Windows. If you NEED to run it with more or less privileges, you can create or use an existing account appropriately, and just tell the broker to use that account - you only need to provide the credentials once, and Windows SCM manages the token generation and caching as per normal SCM rules, and when you try installing it you would obviously need sufficient rights to use that account AND install a service. I'm pretty sure this all meets guidelines, as I'm never violating any security rules that I know of... (and I'm a hardcore security / crypto geek, 25+ years...) If you would like me to disable the self-installation features before patch, I certainly can... Kerry On Thu, Apr 1, 2010 at 9:33 AM, Andrew Stitcher <[email protected]>wrote: > On Tue, 2010-03-30 at 11:21 -0500, Kerry Bonin wrote: > > Hello, and thanks for the comments! > > > > First, thank you Andrew for GetCommandLine() - 20 something years on > > Windows, and I don't remember seeing that one before, certainly made this > > simpler. > > > > On the subject of the command line in general for a service - I agree > that > > under most normal use a config file should be used, I just wanted to make > > sure the command line was usable... > > > > On the security of self-installing services - if the service is doing > much > > more than installing itself, especially if it contains baked in > credentials, > > ect., that would be a very bad thing. What I've done is essentially the > > equivalent of sc create|start|stop|delete wrap as a convenience function, > > nothing more, and the calls execute with the same privilege level a user > has > > available to them at the command line. > > ISTR that the issue is related to UAC, but I admit I can't quite see > what the issue could be. > > One security related issue I'd suggest is that if running qpid as a > service then we should run as an unprivileged user though with network > access. qpidd only shuffles bits around a network so doesn't seem to > need elevated privileges. > > I'm not sure how this fits exactly, but I assume that you'd need to > create a new user account on installation and run the service using it. > This would obviously require admin privileges. > > Andrew > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
