Hi, Nato -
nathans wrote:
> [...]
> Attached patch is an initial stab at solving the problem. It
> takes the following tack:
> - add a new "pcp" user and group [...]
Right.
> 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.)
> - when running in daemon modes, all of pmcd, pmlogger, pmie &
> pmproxy run their main loop as user "pcp" (maybe pmproxy is
> ok to stay as user "nobody"? could go either way I guess)
OK.
> - also via packaging trickery, recursively change ownership of
> /var/log/pcp/pmlogger/<hosts> dirs [...]
OK.
> - 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, then it can't seteuid back & forth
between pcp and root / other users. (It should be fully unprivileged
if at all possible.) So, we'd probably need a setuid-root helper
program that launches pmdas. But then the pmdas themselves don't need
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.
> - 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.
> - 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?
(An unprivileged user running "new_pmcd -U root" mustn't work :-)
- FChE
|