On Wed, Sep 24, 2008 at 11:27:39PM +0200, Tobias Oetiker wrote: >> ( Also, keep in mind that realpath() will also resolve sym-links and >> ../../etc. This is important when we consider that the rrdcached data >> structure only keys by strcmp(). If the client makes it absolute that >> is very helpful ) > > it will no resolve bind mounts I guess ... ?
Not sure what you mean. >> (I1) as a local service >> - purpose is largely to ease disk burden >> - cannot expect users to know cached is present >> - optimize for the use cases that work today >> - i.e. refer to file by any valid path > > yes this was the original idea, i think we got this pat-down. The > only issue to solve here is how to provide read-only access through > the daemon for setups where some users can read the rrds while > others can read and write ... I like the two-sockets approach.. Let the users pick which sockets are read-write vs. read-only, and advise them to protect the read-write sockets with UNIX permissions.. Optionally, force inet sockets to be read-only. > one option here would be to service two sockets, one allows all > operations while the other only accepts the flush commands. The two > sockets would go into two sub directories with different user > permissions it would not be as fine grain as the file system, but it > should get us along way. The read-write should be a Unix-domain socket protected by the same Unix permissions as the RRD files themselves. Anyone that could write the files could also just clobber the RRDs. The read-only socket can be a network socket on localhost.. This is what I'm doing on my environment. All users inherit the $RRDCACHED_ADDRESS environment variable when logging in, and it points to the network socket. Once I add the read-vs-read/write, I'll start pointing my pollers to a separate, protected, Unix socket. > another option would be to identify the process that is connecting > the socket (at least on linux this is possible as fahr as I know) > the daemon could then ensure that the owner of the process has the > respective rights on the rrd file. Not portable at all. > Maybe we should forget about 'remote access' alltogether. After > all, we are duplicating effort here in designing yet another server > ... even rrdtool itself can be run as a service via inted. Yes, let's get rid of it for now. The protocol is simple enough to implement; if someone needed remote socket operations they could (theoretically) write their own client. > In the real world, the while networking stuff may well happen in > the application layer above rrdtool. After all there is no real > advantage in being able to run rrdtool update remotely as oposed to > pushing the numbers collected to a webserver or some other service > on the server. This would relieve us from even thinking about all the > remote access issues. I think it's best left for later. Patches to follow... -- kevin brintnall =~ /[EMAIL PROTECTED]/ _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
