This sounds great, Kerry. Looking forward to seeing it. -Steve
> -----Original Message----- > From: Kerry Bonin [mailto:[email protected]] > Sent: Thursday, April 01, 2010 1:30 PM > To: [email protected] > Subject: Re: Access to qpidd original arg list from {platform > specific}QpiddBroker.cpp ? > > > LocalService still has access to the network, and is > generally preferable over NetworkService - NetworkService > tries to use the domain account privileges it is running > under, whereas LocalService is treated as an anonymous > network agent. A hacked service running under NetworkService > will therefore have more privileges in the local network than > one running under LocalService, so unless you need to > interact with the domain, LocalService is preferred for > network services. > > On the service abstraction issue, I've now been able to > contain all the Windows service code to the Windows specific > QpiddBroker.cpp, and reverted all my changes to qpidd.cpp. > (Although I am adding a WinService .cpp/.h with my generic > service helper class.) So the platform abstraction is as > clean as possible on the Windows side. The only other > interaction between the service code and the broker is during > shutdown, in which case I preserve the Broker * and call the > shutdown() API. > > I've added --start-type={auto|demand|disabled}, and now > working on --account, --password, and --depends (register > list of dependent services), all as per SCM conventions. > Also looking at QPID-1423... > > > On Thu, Apr 1, 2010 at 12:14 PM, Andrew Stitcher > <[email protected]>wrote: > > > 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] > > > > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
