G'day Frank.
On 09/05/13 08:47, Frank Ch. Eigler wrote:
...
There are a couple of problems with this. The worst one is that these
1777 directories open up the system to interference from malicious
local users, leading to DoS or worse.
Given that /var/tmp and /tmp and at least half a dozen other directories
I can find on my system are likely to exist and be mode 1777, the evil
ones already have ample opportunity even if PCP is not installed. I am
not strongly persuaded by this argument I'm afraid.
Also we already have /var/tmp/pmlogger and /var/tmp/mmv that are mode
1777 and there is no Plan B that is possible for these (the pmlogger one
is not negotiable as any uid can launch pmlogger, e.g. "Record" mode for
gui tools, the mmv one I'm less sure on).
But from a philosophical view, I agree using group and user permissions
would be cleaner for the PMDA logs and indom cache files.
If these PMDAs really must run
under userids that can't share a supplemental group (to allow 0770
privileges), then perchance have the pmda/Install files create a
config/pmda/$PMDA or log/pmcd/$PMDA subdirectory for each, with proper
permissions. More work, but it's Righter.
Some DB APIs have (at least in the past) relied on some db-group
permissions, so we may not have the freedom to mandate running as gid pcp.
But, I do agree that since the PMDA Install script runs as root, it
should be able to create/chmod/chown the relevant files to match any
unusual PMDA permissions situations.
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.
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.
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!
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.
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.
|