Hi.
I am sorry for the late answer, too much work left on my desk after I
returned from a trip.
Am Montag, den 08.10.2012, 18:23 -0400 schrieb Nathan Scott:
> Hey Thomas,
>
> ----- Original Message -----
> > Hi.
> >
> > 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.
>
> I guess you mean if we used seteuid originally (and not setuid) to set
> the user away from root? Such that pmcd can then switch back to root,
> temporarily, when SIGHUP arrives and it can (re)start child processes?
I was really thinking about dropping the privileges completely with
setgid() and setuid(). An init/rc scripts executed by root/init could
restart the client processes that needs UID=0 and the network process
that does not need UID 0.
Maybe using fscaps instead of UID=0 is another option to reduce the
privileges of pcp.
>
> > Does restart mean "exit and exec"
>
> Yeah, we can't do that - that'd terminate client connections (more
> detail on the issues that causes below).
>
> > or just resetting the configuration of the running processes?
>
> Yes, but thats not a "just", it involves starting child processes which
> may need to run as e.g. user "postgres". When pmcd runs as root this
> is not a problem, but as an unprivileged user it presents challenges of
> course.
Do fscaps help here?
>
> > > 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?
>
> Correct, and it is TCP-based. In particular, for the PMDAs exporting
> event data, which involves per-client state, restarting pmcd (and all
> existing PMDAs) is particularly disruptive & so not really an option.
> Even for the "regular" PMDAs exporting sampled metrics, having to end
> all their connections means they will miss their next value while they
> reconnect and re-establish their state (rate converting counters means
> client side state held from previous sample, which gets messed up on a
> reconnect). Definitely we want to avoid client reconnects which means
> SIGHUP handling has to be smarter than just restarting pmnd.
Does a SIGHUP occur often, so that the pain is high enough to take care
of it?
Which part of pcp needs to update the configuration? The network process
or the privileged child processes?
> > 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.
>
> Yeah, possibly, either way the solution is starting to get complex ...
> I guess we've circled back to my original point anyway, that its a bit
> of a non-trivial problem. :)
Yes, looks like it is complex and rewriting it needs special care of the
design.
Bye
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
|