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: us...@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 t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
