Hey Frank,
Thanks for looking it over.
----- Original Message -----
>
> > I *think* it has to be a fixed ID, as we'll be persisting pmlogger
> > logs, etc with this UID/GID. [...]
>
> (I don't see why. Files transferred between systems do not need
> to preserve their numerical uid/gid's.)
>
I was thinking that archives created below /var/log/pcp/pmlogger/<host>/*
would need to have consistent IDs but perhaps not. I can't really see a
good reason why they should ... will assume not unless someone can think
of something.
>
> > - adds __pmSetProcessIdentity() used by everyone (changes the
> > existing perl PMDAs to use it, uses it in pmcd & co too). Add
> > thread safety to the existing (perl wrapper) code while at it.
> > In the end, all callers use the same code to switch user.
>
> Can you elaborate upon this part of the model? How do you imagine the
> pmcd-invoked pmdas to be able to use it?
>
> If pmcd is fully unprivileged,
pmcd always gets to run initially as root (bootup/service start)...
> then it can't seteuid back & forth
> between pcp and root / other users. (It should be fully unprivileged
> if at all possible.)
*nod*. The patch does a full privilege drop just before entering the
main event processing loop (but after starting all agents which run as
root unless they choose to not do so). Many do already, without this
patch, using a perl API to switch user (the database pmdas tend to do
this, and several others). I know of one production deployment which
also has done this (directly in C) so their PMDAs don't run as root.
> So, we'd probably need a setuid-root helper
> program that launches pmdas. But then the pmdas themselves don't
> need
I think (hope) we can avoid any setuid helper.
> to take action (in the form of that api call), since by the time they
> are invoked, they'd be already running at reduced appropriate
> privilege.
They run as root from startup. They don't get that option at sighup
time, anymore (which accompanies a ./Install), but they can now say
in their Install scripts that they require a full pmcd restart).
I'm currently thinking this tradeoff gives the best balance of backward
compatibility, security, and functionality ... the full restart is a bit
of a "big hammer", but its a tradeoff for those PMDAs that cannot run as
"pcp" user.
>
> > - adds a "forced_restart" variable to pmdaproc.sh which allows
> > an agent to request pmcd be restarted rather than SIGHUP'd when
> > it is ./Install'd. [...]
>
> If you have a setuid wrapper program for launching non-pcp pmdas,
> that
> wrapper could have a SIGHUP-sending mode.
>
Not clear whether the setuid wrapper is really needed (and having it
opens a window for security issues, so I'd prefer not to if possible).
>
> > - adds -U <username> to all daemons so that root could be gone
> > back to temporarily, easily, if theres some problem or maybe if
> > someone wants some other unusual setup.
>
> How would this be used? root invoking modified initscripts?
This option could be used to start pmcd as root once more, as a
fall-back in case someones deployment still requires it.
The initscripts wouldnt need to be modified...? (pmcd.options file
has this option)
> (An unprivileged user running "new_pmcd -U root" mustn't work :-)
Yep, indeed, that wouldn't work.
cheers.
--
Nathan
|