On Wed, Apr 08, 2009 at 02:18:58AM -0500, kevin brintnall wrote: >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:
Just curious as to why not just use the existing infrastructure (hosts.allow, hosts.deny)? # allow user1 on box1 and everybody on the local net except that one bad box rrdcached: [email protected], .foo.internal EXCEPT badbox.foo.internal And if you really want the user to authenticate then reuse pam (pam_start(), if pam_authenticate() != PAM_SUCCESS fail()) What am i missing? > >* 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? _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
