[rrd-developers] [PATCH] rrd_client: Do not rewrite path names when accessing remote daemons.

[Benny Baumann]

Hi,

Am 04.10.2009 00:46, schrieb Sebastian Harl:
> Hi Benny,
>
> Thanks for your feedback!
>
> On Sat, Oct 03, 2009 at 11:54:53PM +0200, Benny Baumann wrote:
>   
>> Am 03.10.2009 23:36, schrieb Tobias Oetiker:
>>     
>>> Today Sebastian Harl wrote:
>>>       
>>>> When talking to a local daemon (thru a UNIX socket), relative path names are
>>>> resolved to absolute path names to allow for transparent integration into
>>>> existing solutions (as requested by Tobi).
>>>>
>>>> However, when talking to a remote daemon, absolute path names are not allowed,
>>>> since path name translation is done by the server (relative to the base
>>>> directory).
>>>>         
> […]
>   
>> IMHO the behaviour should mor be like:
>> - Requests are always rewritten
>>     
> In what way would you want a request, that is sent to a remote daemon,
> to be rewritten (on the client, as this what we're talking about)?
>   
Do I get this right that you're rewriting paths once locally (on the
client) and again (remote) on the server side?

Any useful example on when you'd want this really to be done locally
instead of on the target (server) maschine?

IMHO the only time a request should be rewritten/mapped is on the server
to determine where to put the file. An example might be when the
pathname you're accessing doesn't exist when mapped as subdirectory of
the RRD file root, but exists when given from the file system root

Example: /var/lib/rrdtool is the RRD file root, and
/var/lib/rrdtool/test.rrd is given as pathname The canonical file
/var/lib/rrdtool/var/lib/rrdtool/test.rrd doesn't exist, but
/var/lib/rrdtool/test.rrd does. Given a second limitation like multiple
"base_dirs" (simular to what PHP does) this might be a nice thing to
allow e.g. "/var/lib/rrdtool:/home/rrd:/tmp:/var/tmp" to define
directories that might appear for pathnames outside the usual chroot.

Doing such mappings on the client really doesn't make sense IMO.
>> - The Cache Daemon defines a root path (simular to an chroot)
>>     
> This is already possible using rrdcached's '-b' command line option. If
> that's not specified, /tmp is used as a default. You may disallow any
> updates to files outside of that directory by using the -B command line
> option. See the rrdcached(1) manpage for more details.
>
> On the *server* side, all relative path names are rewritten to be
> relative to that base directory.
>   
k.

So on the *client* side there's no mapping done?
>> - Every request, independently of being absolute or relative, is
>> interpreted relative to this root directory.
>>     
> Hrm … imho this option would be fine as well, *if* absolute path names
> would not be treated differently when accessing a local daemon (which is
> requested by Tobi). Adding another difference to the handling of path
> names would be way too confusing imho.
>
> OTOH, when thinking of the base directory as something like a chroot,
> this might make some sense. What do others think about that?
>   
Cf. my comment on the first point:
- define one "working directory" that is used to treat paths on the server
- if a file cannot be found that way use the file system root (for
absolute paths only) and check against a whitelist of "basedirs" where
access is allowed.

For *local* access the RRD root would be /tmp or /var/lib/rrdtool (or
something like that) and the basedir would be "/" (Given nothing else
was specified).
> Cheers,
> Sebastian
>   
Regards,
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20091004/46e4a7b4/attachment.pgp