Hi Thomas,
----- Original Message -----
> Hi.
>
> I am sorry for the late answer, too much work left on my desk after I
> returned from a trip.
>
No problem, thanks for sending it - helps to go through issues/options.
>
> 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
> > > 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().
That would be my preference too, its simple and effective. There's the
issue around sighup handling, but I'm starting to think that (since no
other more appealing option seems to exist) perhaps a tradeoff where we
just attempt agent starts as non-root with SIGHUP, which will work for
all agents that don't need to change user (hopefully many of them), and
for the rest it could become a sysadmin-managed issue of issuing a full
pmcd service start for those agents.
IIRC, there is a little-used mode where PMDAs can be already running at
the time pmcd starts, and pmcd connects to them (rather than starting
them as children). Perhaps we'll need to do more of that now too.
> Maybe using fscaps instead of UID=0 is another option to reduce the
> privileges of pcp.
*nod*, yes, another option. Not portable though, but for Linux maybe a
good option.
> Does a SIGHUP occur often, so that the pain is high enough to take
> care of it?
It doesn't happen often, but its very painful. I'm starting to wonder
if we just have to give ground on this, and for those agents that need
to run as root or another special-case user (like postgres), they will
need to be handled "specially" with a disruptive service restart.
I'm starting to look into this more deeply this week, so we should see
a series of changes in this area soon.
cheers.
--
Nathan
|