[rrd-developers] [rrd] Why / How / When is version 1.2 developed?
tobi at oetiker.ch
Wed Apr 8 18:19:19 CEST 2009
Today Bernhard Reutner-Fischer wrote:
> 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,
> # allow user1 on box1 and everybody on the local net except that one bad box
> rrdcached: user1 at box1.foo.com, .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?
* hosts.allow is trust based and this is not the way to go for new
* pam is primarily for 'user' authentication and linked to a single
database, here we have 'system authentication'.
* for system authentication the shared secret (or if it has to be
more complex a certificate) aproach is 'the norm' and works very
well in my experiance.
> >* 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.
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
More information about the rrd-developers