> Tobi, > > Do you think this is a reasonable approach? > > * Create the notion of a read-only command channel (i.e. "stats" and > "flush") This makes sense when you consider that RRD files would be > written by a single user (i.e. poller) but read by multiple users > (i.e. web server creating graphs, program that dump/fetch/etc). This > could be network or unix domain socket.
You mean for cases where the filesystem with the rrd files is nfs shared or something like this ? I guess that could work, but there is still a DOS vulnerability since the rrds in the shared filesystem are exported 'per user & per machine' while the network socket is only 'per machine' as long as there is no authentication. > * the read-write socket can be limited to unix domain sockets, and > protected by unix perms. If a user had write access to the socket, > they would likely have write access to the RRDs. > > For a shared secret, I see some complications with passing it from > user-->api-->daemon cleanly, and managing the associated state in the > daemon. Did you have anything in mind for that? My thinking is, that without the daemon, accessibility of rrd files is governed by normal filesystem permissions. So if we had a shared secret in a file, this could give us the same level of security over the network (especially if it was coupled with the ip of the sender machine). My idea is, that when specifying daemon mode via commandline or environment, this would also have to include the name of a file containing a username and a shared secret. rrd would then createn an HMAC-MD5 hash of 'command + secret' and append this along with the username to the command it sends to the rrdcached. the rrdcached itself has a secrets file like this #user mask access secret alpha local rw djdjddiyiuyiuyilhjgdf beta 192.168.2.1 r lkdu[oiuohakjdsfjhk gamma 111.2.23/24 rw lkjasdasdfaskfsfdl alpha 122.3.2.2 w djcne8394jfnfdklakd so that it can verify the secret that is being sent to it ... like this we can recreate a security level similar to what is provided by the filesystem. Obviously both sides would cache their secret and as such it would not present any kind of significant performance impact I would assume. Am I missing something? > > b) it must be possible to set a (virtual) root directory for the > > daemon, so that it does not soly rely on permissions being > > properly set. > > How about this.. if a base directory is specified (-b <base>) and a command > comes in with an absolute <path>, then enforce: > > <path> starts with <base>/ that sounds fine yes. chees tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
