[rrd-developers] [rrd] Why / How / When is version 1.2 developed?

kevin brintnall kbrint at rufus.net
Wed Apr 8 09:18:58 CEST 2009

On Wed, Apr 08, 2009 at 07:38:06AM +0200, Tobias Oetiker wrote:
> I have been telling people about the daemon feature at recent talks
> and the auth question came up often ... the reason fetch is tipping
> the scale for me is that with this functionality rrdcached goes
> from a 'submit only' server to a 'read/write' server ... and
> providing something read/write over the network without
> authentication is a recepie for trouble in my book. and after all,
> it is my name associated with rrdtool ...

Tobi et al,

Here is what I'm thinking for authentication:

* server has a list of secrets that it accepts
  * easier than user:pass mapping, which is overkill IMO
  * allows for secrets to be rotated with overlap time.. no flash cut

* some sort of challenge/response authentication would be nice
  * pick something easily implemented in 3rd-party rrdcached client
  * i.e. CRAM-MD5 ? (concerned with MD5 weakness?)

* a place to stash the secret
  * by default, some file like $HOME/.rrd*
  * override with some environment variable?
  * modify all APIs to pass on the command line ??

* successful authentication can turn an un-privileged socket into a
  privileged one.
  * this still allows any user to execute things like "flush", "stats", etc
  * operations privileged sockets still don't require auth

On the wire, looking something like:

     C:  AUTH
     S:  1 Challenge:
     S:  <nonce>
     C:  AUTH <nonce> hash(<nonce>,<secret>)
     S:  0 AUTH OK
  or S:  -1 AUTH FAILED

     C:  AUTH
     S:  0 Not required.


 kevin brintnall =~ /kbrint at rufus.net/

More information about the rrd-developers mailing list