qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kerry Bonin <kerrybo...@gmail.com>
Subject Re: Access to qpidd original arg list from {platform specific}QpiddBroker.cpp ?
Date Thu, 01 Apr 2010 17:29:50 GMT
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 <astitcher@redhat.com>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:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message