On Thu, 2010-04-01 at 11:46 -0500, Kerry Bonin wrote: > 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.
Doesn't it have to be the 'NETWORK SERVICE' account for it to have access to the network? which you'd think it would need! In more recent versions of windows the service accounts are split. > > 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... No need, I was working from a faulty memory, and I can't think of any good reason to exclude this functionality. I suspect the much bigger issue is going to be how the Unix daemonisation and the Windows service code are both abstracted so that the code becomes easier to maintain. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
