[rdiff-backup-users] Adding (not just enforcing) a prefix for paths in server mode

[Charles Duffy]

Howdy. I'm interested in adding a new option to rdiff-backup to enforce 
a prefix for local paths in server mode -- not by throwing an exception 
if a path is requested outside this prefix (as done by the --restrict 
option), but by prefixing this path to all requests made.

This will allow me to securely provide backup service to a number of 
different remote systems, and preventing them from getting into each 
others' files, by forcibly including their hostname in the rdiff-server 
command line. (I'm kicking off rdiff-server from a tcpsvd instance with 
instructions to reject connections not coming over a VPN; consequently, 
while it's not running over SSH, it's an authenticated connection, and 
it's strictly code local to the server which determines rdiff-backup 
server arguments being used).

The issue here is that I'm not sure *where* would be the appropriate 
place to enforce such an option.

vet_request() would seem to make sense, but I'm not sure if actually 
modifying the request here is acceptable -- RORPath objects are
supposed 
to be immutable, right? Can they be seen in this location? What's the 
distinction between the base and data elements for an RPath? If I'm 
trying to modify a local RPath to add a prefix, am I correct in 
understanding that it should be added to the base?

So, the options I'm considering:

    * Add it in vet_request() before --restrict validation? (Are all
      paths passed through here mutable at this point?)
    * Add the prefix in the RPath constructor? (What would this do to
      RPaths being constructed off another one, ie. via normalize()?)
    * Give up and put the whole thing in a remote-host-specific chroot
      jail? (Wouldn't this mean putting a copy of the Python interpreter
      in there too? eww!)
    * Give up and give the remote hosts knowledge of the local
      filesystem structure and use --restrict (and then need to update
      the software on all the remote hosts if I ever change FS structure
      on the server -- eww!)
    * Something else I've missed?

Suggestions would be very, very welcome. Thanks!