[rrd-developers] [RRDCacheD] Authentication (was: Why / How / When is version 1.2 developed?)

[Tobias Oetiker]

Hi Florian,

Today Florian Forster wrote:

> Hi Tobi,
>
> 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 ...
>
> interesting point that ?write? without authentication is less of a
> security concern than ?read/write?.

well in the sense that no 'secret' information can get out ... but
you may remember that I raised this question right when the whole
daemon thing started ...

> > and providing something read/write over the network without
> > authentication is a recepie for trouble in my book.
>
> My point of view is that currently, RRDCacheD is simply not suited to be
> used in the public without protection. If people don't like this,
> they're free not to use the daemon. If they want to use the daemon, it
> is (always!) their responsibility to ensure security and currently this
> means setting up a firewall/packet filter, VPN, tunnel or use only UNIX
> domain sockets. And if all that doesn't fit their bill they should ? in
> the best of all FOSS traditions ? ?submit patches!?
>
> Please note that I'm not at all against implementing authentication. I'm
> only arguing that currently it's not available and people have to cope
> with that one way or another. Keeping out features because of that is
> not the way to go in my opinion.

my problem is that in the end my name is tied with rrdtool and
people WILL use it unresponsible and wrongly ... I am sure ... so
if we do not even provide security this might be a PR night mare
for me ... which I would rather avoid

thinking about it, linking it to the fetch funnctionality is wrong
indeed, we need it anyway for 1.4

> > I am sure create / delete / tune ... will follow shortly ...
>
> Of course they will, and therefore it's a good idea to ?think big? from
> the beginning. The privileges currently implemented (the ?-L? option)
> will not nearly match the demands people will have. We should seriously
> rethink that concept and come up with something more flexible. For
> example, make is possible to specify which commands are allowed on the
> command line:
>   --allow flush,flushall,update
> or
>   --deny flushall
>
> This would make the argument of ?commands too dangerous for not having
> authentication? obsolete once and for all, because everybody can decide
> for himself which commands are okay to use in the current environment.
>
> Last but not least, authentication without encryption creates a wrong
> sense of security that is much more dangerous than not having any
> security at all and people knowing about it. So we should think about a
> ?STARTTLS? command (or similar), too.

no problem, with making it more complete, for 1.4 I am happy with
authentication by shared secret. As for ssl support I would want to
make sure that openssl is optional (as is starttls).

cheers
tobi


> Regards,
> -octo
>

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