Hi,

I spoted few important issues which should be solved in rrdcached,
before somebody get hurt.

I think it would be very good to make rrdcached chrootable,
and indeed chroot it by default.

There is no operation which needs root permision there,
and also considering rrdcached could be setuped to listen
on TCP socket, I think it should be secured (I know
it already should be secured in firewall, but if rrdcached
is gethering rrd updates from lots of different servers,
there is always probability one of them will be compromised
and used to perform attack.)

Also there is no particular reason rrdcached should be running as root,
as it is now. There should be separete user/group for it,
and all file operations (maybe exluding initial socket creation)
should be done as it.

It also will simplify rrd reading. Currently one needs to be read
rrd files, for example to create graphs or analyze them in other way.
Starting rrdcache as other user, groups, and allowing specifing
permisions and owner/group of new files will make it much easier,


Also manpage says

"
  The daemon will blindly write to any file it gets told, so you really should
create a
       separate user just for this daemon. Also it does not do any sanity
checks, so if it
       gets told to write values for a time far in the future, your files will
be messed up
       good!
"


So, please follow this nice recomendation.

Thanks you.

Hi,

Agreed that making RRDCacheD chrootable is a nice idea. Making that the
default *in Debian* might make sense as well, but that won't happen
upstream as the upstream default config allows to write to arbitrary
locations anyway (which is done on purpose to allow for transparent
drop-in setups -- I've argued against that in the past several times so
please don't bring that up again ;-)).

So, I'd go for a new command line option to configure that and use that
by default in the init script (making it overwritable in /etc/default/
rrdcached).

Well, it could use root permissions e.g. to open different UNIX sockets
belonging to different users/groups.

Well, I'm not sure if it makes sense to let an unprivileged process
listen on a privileged port. I'd rather go for letting start-stop-daemon
handle the user/group stuff. Do you see any other benefits from doing
that differently?

Thanks for your report!

Cheers,
Sebastian