pcp
[Top] [All Lists]

Re: pcp updates - assorted non-trivial changes

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: pcp updates - assorted non-trivial changes
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Thu, 9 May 2013 07:53:19 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <518B1217.2020307@xxxxxxxxxxxxxxxx>
References: <518ABC53.2090207@xxxxxxxxxxxxxxxx> <y0ma9o55bs8.fsf@xxxxxxxx> <518B087D.702@xxxxxxxxxxxxxxxx> <20130509024318.GA19133@xxxxxxxxxx> <518B1217.2020307@xxxxxxxxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi -

On Thu, May 09, 2013 at 01:03:51PM +1000, Ken McDonell wrote:
> [...]
> > (Could these programs not log to some $HOME/.pcp directory?  Why
> > should they be system-wide?)

> The pmlogger ones really have to be system-wide ... the whole
> (distributed) pmlc-pmcd_PMDA-pmlogger control infrastructure depends
> on pmcd.pmlogger.* metrics being available and reflecting the state
> of all pmloggers running on the local host.

That seems overly invasive for exposing data on private people running
private pmloggers for their private purposes.  Can't this be opt-in,
or depend on userid?  Is it even safe for a system daemon to trust &
rebroadcast data from some random unprivileged pmlogger?


> >> 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.
> > 
> > Can you give an example?
> 
> Here is a fragment of the Debian policy enforcer ...
> 
>        dh_fixperms makes all files in usr/share/doc in the package build
>        directory (excluding files in the examples/ directory) be mode 644. It
>        also changes the permissions of all man pages to mode 644. It makes all
>        files be owned by root, and it removes group and other write permission
>        from all files. [...]

That sounds like debian removes group-write permissions from all
files, which would be surprising.  The bulk of the items seem like
sound canonicalization from a security/consistency perspective.

> >> 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.
> > 
> > Can you give an example?

> [...]  I forced some mode 1777 directories into the tarball in the
> .deb package, installed the package and the modes of the directories
> were unchanged (although this will also have run the pre-install and
> post-install scripts, and our rc scripts before I checked the
> permissions on the directories).

It sounds like the debian one-time post-install scripts would be the
place to set permissions that are not-quite-right after untarring,
rather than the system reboot-time rc files.

- FChE

<Prev in Thread] Current Thread [Next in Thread>