Hi Ken,
----- Original Message -----
> ...
>
> I guess we could try the group permissions thing ... first change would
> need to be adding setgid in the same place we call setuid in libpcp.
It does a setgid now - src/libpcp/src/util.c::__pmSetProcessIdentity
> And pmcd will drop its privileges to pcp:pcp. This needs to be done
> _before_ any PMDA is launched so that the PMDA's see the same initial
> privileges independent of when they are started ... /etc/init.d/pmcd
> start time has to be the same as a PMDA Install, or PMDA Remove, or
> SIGHUP to pmcd.
>
> Then any PMDA that is not happy running as pcp:pcp would need to be a
> non-DSO PMDA, running a setuid (and/or less likely setgid) binary to
> change the privileges.
Hmmm - that cure (setuid pmdas) sounds alot worse than the disease!
> I am not sure what to do here in the 3.8.0 timeframe.
>
> > Also, rc.d/init.d files should not chmod files or directories at run
> > time. Permissions should be set by the installation scripts, and
> > maintained thence; else routine package-verification will fail and set
> > off alarms.
> >
>
> This is a different can of worms!
*nod*
> 1. some packaging systems enforce permissions and uid/gid rules that are
> not consistent with our needs ... so we need to gather all these up and
> replicate the patch up logic in _all_ the package post-install scripts.
>
> 2. some packaging systems don't honour changes in permissions and
> uid/gid from the package when these are different to permissions and
> uid/gid settings of an already installed file or directory.
>
> 3. some of our directories are created on the fly and not included in
> the packages ... this is almost certainly wrong.
I'm not sure we have any in case #3 anymore ... which ones do you have
in mind there?
> This is why we have "fix up" logic in the rc scripts.
>
> All this is fixable (1. would fix 2., 3. _could_ be done independently),
> but based on previous experience very risky (we need full coverage of
> the upgrade and virgin install matrix) ... I think we should consider
> this for some release post 3.8.0
>
> If we can agree on a plan of attack for these items, I'll do the
> bugzilla legwork for the consequent backlog issues.
It seems we need to undo some of these changes that were pulled in
earlier today, and re-group (heh) for a post 3.8.0 tilt at the issue?
In the short-term, we could address the indom cache problem via some
judicious Install script tweakery. In fact, I wonder if pmdaOpenLog
could acquire a helper routine to ensure the log files it creates as
root initially can be written to by whichever user the PMDA chooses
to change-user to later? (and keep the status quo)
Given the only PMDA that is seeing the cache issue is pmdasimple, and
the default for out-of-tree PMDAs is to run-as-root still (hence no
logfile permissions issues) ... it would seem there's no urgency to
address this in 3.8.0 - a subsequent point release would be fine, no?
cheers.
--
Nathan
|