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 OR C: AUTH S: 0 Not required. Thoughts? -- kevin brintnall =~ /kbr...@rufus.net/ _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers