[rrd-developers] rrdcached daemonize failed, exiting

[Tobi Oetiker]

> Tobi,
>
> Do you think this is a reasonable approach?
>
>  * Create the notion of a read-only command channel (i.e. "stats" and
>    "flush") This makes sense when you consider that RRD files would be
>    written by a single user (i.e. poller) but read by multiple users
>    (i.e. web server creating graphs, program that dump/fetch/etc).  This
>    could be network or unix domain socket.

You mean for cases where the filesystem with the rrd files is nfs
shared or something like this ? I guess that could work, but there
is still a DOS vulnerability since the rrds in the shared
filesystem are exported 'per user & per machine' while the network
socket is only 'per machine' as long as there is no authentication.

>  * the read-write socket can be limited to unix domain sockets, and
>    protected by unix perms.  If a user had write access to the socket,
>    they would likely have write access to the RRDs.
>
> For a shared secret, I see some complications with passing it from
> user-->api-->daemon cleanly, and managing the associated state in the
> daemon.  Did you have anything in mind for that?

My thinking is, that without the daemon, accessibility of rrd files
is governed by normal filesystem permissions. So if we had a shared
secret in a file, this could give us the same level of security
over the network (especially if it was coupled with the ip of the
sender machine).

My idea is, that when specifying daemon mode via commandline or
environment, this would also have to include the name of a file
containing a username and a shared secret.

rrd would then createn an HMAC-MD5 hash of 'command + secret' and
append this along with the username to the command it sends to the
rrdcached.

the rrdcached itself has a secrets file like this

#user mask      access secret
alpha local       rw   djdjddiyiuyiuyilhjgdf
beta  192.168.2.1 r    lkdu[oiuohakjdsfjhk
gamma 111.2.23/24 rw   lkjasdasdfaskfsfdl
alpha 122.3.2.2   w    djcne8394jfnfdklakd

so that it can verify the secret that is being sent to it ...

like this we can recreate a security level similar to what is
provided by the filesystem. Obviously both sides would cache their
secret and as such it would not present any kind of significant
performance impact I would assume. Am I missing something?

> > b) it must be possible to set a (virtual) root directory for the
> >    daemon, so that it does not soly rely on permissions being
> >    properly set.
>
> How about this..  if a base directory is specified (-b <base>) and a command
> comes in with an absolute <path>, then enforce:
>
> 	<path> starts with <base>/

that sounds fine yes.

chees
tobi

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900