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

[Sebastian Harl]

Hi Benny,

On Sun, Oct 04, 2009 at 02:22:40AM +0200, Benny Baumann wrote:
> Am 04.10.2009 00:46, schrieb Sebastian Harl:
> > 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?

Nope. The client rewrites path names only when talking to a daemon thru
a UNIX socket. In that case, a relative path name is prepended by the
current working directory. The daemon only rewrites relative path names,
so the two are mutually exclusive.

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

The client side rewrite is done to allow for transparent integration of
RRDCacheD into existing solutions - see the previous discussions …

> 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

Full ack. This is what I've stated numerous times in the past. This is
what is now done when accessing a remote (i.e. thru a network socket)
server. The reason to handle access to local daemons differently is a
compromise to ease the transition to RRDCacheD.

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

Right.

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

Exists already.

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

Hrm … this would add a whole lot of magic to the path name handling,
which imho is not worth it. What benefits do you expect from doing that?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20091004/e309558b/attachment.pgp