Hi.
Am Dienstag, den 02.10.2012, 20:37 -0400 schrieb Nathan Scott:
> Hi Thomas,
>
> ----- Original Message -----
> > Hello Frank,
> >
> > Am Montag, den 01.10.2012, 15:56 -0400 schrieb Frank Ch. Eigler:
> > > thomas wrote:
> > >
> > > > [...] Would it be possible to run the code that processes the
> > > > network data without UID and GID 0? [...]
> > >
> > > We've started thinking about this problem some time ago, and will
> > > start working on it shortly. My favorite approach so far is to
> > > have pmcd run as an unprivileged user, talking to & managing
> > > differently-privileged PMDA processes as configured (or requested
> > > by an authenticated remote pmcd user).
> >
> > This sounds good.
>
> *nod* - the difficulty is in figuring out how to make an unprivileged
> pmcd able to start these privileged child processes (which it usually
> communicates with via pipes). At startup it's relatively easy (pmcd
> starts initially as root, could then change its uid/gid after starting
> the agents) but pmcd also needs to be able to be sent SIGHUP and (re)-
> start its children.
Who should be able to send the SIGHUP? If it is only root, then you can
use the solution with dropping privileges like you did during normal
system boot.
What should happen when a SIGHUP is received? Does restart mean "exit
and exec" or just resetting the configuration of the running processes?
Updating the config of the privileged client process could be done over
a unix domain socket (and the clients have to verify the peers UID) or a
dedicated pipe (not over the same pipe that is used to transfer client
requests).
> And without disruption to any of pmcd's existing
> client connections. Perhaps a setuid helper could do this bit somehow
> but this is the bit that's not really clear in my head at this stage.
Hm, so if you want to not interrupt the client connections you don't
want to exit the process I assume, or are you using UDP?
What about two completely separate processes? The unprivileged one which
handles the client connections could buffer client requests during the
restart (exit/exec) of the privileged process.
Apache might be a good source of a solution too. Unfortunately I don't
know the technical details of the apache implementation.
> > Can you estimate when this new design will be implemented and
> > released?
> > Even a rough estimation would be very helpful for me.
>
> I'm finishing up work for a pcp-gui update at the moment with several
> new features; this is then the next big chunk of work I'll be looking
> at afterward. Any/all help you can offer would be appreciated too of
> course!
It looks like the init scripts also have tmp file issues. David, our
maintainer, will send you the patch if done.
> > ... The process of
> > going to a higher version of a package for our enterprise products
> > is costly ...
>
> *nod*, understood. In order to assist, I'd recommend getting the PCP
> testsuite running locally (see list archive for details), and getting
> the tests passing on a current SLES setup. Then you guys'll be in a
> good place to start testing the new mode (and testing spec file tweaks
> to register a new "pcp" user/group, etc, which is likely to be needed).
Thanks for the hint!
Cheers,
Thomas
--
Thomas Biege, Project Manager Security, CSSLP
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
--
Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
-- Marie von Ebner-Eschenbach
signature.asc
Description: This is a digitally signed message part
|