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

[Tobias Oetiker]

Hi Bernhard,

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,
> hosts.deny)?
>
> # 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
  systems

* 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.

hth
tobi

> >
> >* 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?
>
>

-- 
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