collectd runs as root unnecessarily

[Andrew Yates]

Binary package hint: collectd

The collectd init script runs collectd as root and does not provide a way to change the user in /etc/default/collectd. Many of collectd's plugins do not require root permissions, so USER and GROUP options should be included in the init script and default file. (It might also be a good idea to run collectd as an unprivileged user by default. A quick test suggests that of the default plugins only 'df' may require root privileges.)

Ubuntu 10.10
collectd version: 4.10.1-2

[Amos Shapira (amos-shapira)]

On 14 March 2011 00:39, Sebastian Harl <email address hidden> wrote:

> Source: collectd
> Version: 4.10.1-2.1
> Severity: wishlist
>
> Hi,
>
> (With this E-mail, I'm also submitting this as wishlist bug report to
> the Debian BTS and I'm going to fix it in my next upload. So, Ubuntu
> should get that as well on the next sync after that.)
>
> On Sun, Mar 13, 2011 at 07:04:39AM -0000, Andrew Yates wrote:
> > The collectd init script runs collectd as root and does not provide a
> > way to change the user in /etc/default/collectd. Many of collectd's
> > plugins do not require root permissions, so USER and GROUP options
> > should be included in the init script and default file. (It might
> > also be a good idea to run collectd as an unprivileged user by default.
> > A quick test suggests that of the default plugins only 'df' may require
> > root privileges.)
>
> Fully agreed.
>

+1 from me there.

>
> Also, I was thinking about (re)introducing a possibility to start
> several instances of collectd with different configurations from one
> init script, i.e. having the init script start one instance for each
> configuration file found in some subdirectory. I'm not yet sure, how to
> handle that properly. I guess, adding an option to /e/d/collectd to
> specify that directory (empty by default) and then ignoring any other
> files (including /e/collectd/collectd.conf) is the way to go.
>
> Any comments, suggestions, questions about that?
>

Yes! That would be great.

The issue I have with collectd is that it forces one host name for all the
entries it reports about.

We need to track shared resources (SAN partitions) which get migrated among
the various RedHat Cluster Suite nodes together with an assigned Virtual IP
and have to keep monitoring them with their own host identifier (so it's
obvious from watching the graphs that we are still tracking the "df", for
instance, of the same SAN partition, no matter which RHCS node it is
currently mounted on). The only way I found so far to achieve that is to
start a separate collectd instance per such SAN disk (I haven't implemented
this, though).

A possibly better way would be to allow an entry to override the host name
it is reported under, and conditionally report it based on, e.g., whether
the given directory is a root of a file system or not.

Thanks,

--Amos

[Florian Forster (octo)]

Hi Andrew and Sebastian,

On Sun, Mar 13, 2011 at 02:39:06PM +0100, Sebastian Harl wrote:
> With this E-mail, I'm also submitting this as wishlist bug report to
> the Debian BTS and I'm going to fix it in my next upload.

I would have liked to answer to that bug as well, but couldn't find it
on bugs.debian.org. Am I missing something?

On Sun, Mar 13, 2011 at 07:04:39AM -0000, Andrew Yates wrote:
> (It might also be a good idea to run collectd as an unprivileged user
> by default. A quick test suggests that of the default plugins only
> 'df' may require root privileges.)

In the vast majority of cases, the "df" plugin doesn't need privileges.
The only problematic case I can think of right now is if some file
system is mounted at "/secret/foo" and the unprivileged user isn't
allowed to read "/secret".

Plugins which do require privileges can be found in the collectd wiki in
the "Plugins requiring privileges" category [0].

Regards,
—octo

[0] <http://collectd.org/wiki/index.php/Category:Plugins_requiring_privileges>
--
Florian octo Forster
Hacker in training
GnuPG: 0x0C705A15
http://octo.it/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.