[MERGE][#109143] Support bzr+ssh://host/~/path

[Andrew Bennetts]

I pretty surprised.  I thought the largest concern would be that with this
patch /~/ would stop users accessing files outside their home directory!
But no-one apart from me has even mentioned it.

Martin Pool wrote:
> 2009/3/18 Andrew Bennetts <andrew.bennetts at canonical.com>:
[...]
> > I don't understand what you mean by “if bzr+ssh is invoked over something
> > other than ssh”.  Perhaps you mean “other than /usr/bin/ssh from OpenSSH”,
> > but if so I don't understand why you think that would be a problem?
> 
> I meant to say if "bzr+" is run over something other than ssh, like
> tcp or http.  Considering those cases just seems to me to indicate
> that this is being solved at the wrong layer.

Only bzr-over-ssh has a default working directory provided by the server,
and it's only because the client gets some say in how the server is started
that it can take advantage of that (as this patch does).  Once the server is
started then all the client can do is issue stateless requests, so there's
no possibility to change a working directory (which would need to affect
future requests to be meaningful).

For bzr-over-tcp and bzr-over-http the client has no direct say in what
directories are being served.  The client gets whatever the server is
configured to give.  That's no different to e.g. plain HTTP.

So you seem to be arguing that it's unreasonable for bzr+ssh to have /~/,
because bzr-over-tcp and bzr-over-http can't?  I don't really see why.  I
don't think it's any more likely to cause confusion than sftp having /~/
when http doesn't.  In fact I'm pretty sure it will reduce confusion.

To be pedantic, SSH servers can be locked down to override the client's
requested --directory and thus render /~/ ineffective... and HTTP servers
could choose to serve different content for a URL based on source IP or
HTTPS client certificates or other out-of-band data, thus creating a
pseudo-homedir effect.  But allowing /~/ to have a special meaning in some
URL schemes isn't so much about what can be done by creative use of
out-of-band data in a server, it's about taking advantage of feature that's
inherently available in some protocols and not in others.  Processes spawned
over SSH have a default working dir that we can usefully take advantage of
if users ask us to with /~/.  Requests to HTTP servers don't.

So, after re-considering those cases, solving at this layer still seems fine
to me.

> > Oh, I think I see what you have in mind.  Presumably the server internally
> > generates file:///~mbp/foo when the client asks for ~mbp/foo via the smart
> > protocol (there's a ChrootTransport between the client and the remote's
> > LocalTransport, but it doesn't matter to this discussion), so you're
> > proposing that the LocalTransport should expand file:///~mbp to
> > file:///home/mbp on the server.
> 
> Yes, that's what I meant.  This would even be somewhat useful in file urls.

Yeah.  But it might make round-tripping paths through file URLs reliably
difficult.  And I'd also worry about the potential cost of calling
os.path.expanduser for every single LocalTransport operation, or the cost of
the extra complexity we'd need to avoid that overhead.

As far as solving at the correct layer goes, if the server wants control
over how e.g. ~mbp is interpreted, then we have a whole VFS abstraction in
bzrlib for that already.  That is, servers can override cmd_serve to use a
different backing transport than LocalTransport, and that transport can do
anything they like.  Rewrite paths to be more convenient, expand ~user dirs,
impose access restrictions...  At some point I'd like to write an example
plugin demonstrating that approach.  AIUI bazaar.launchpad.net's bzr+ssh
server works this way.

> > I suppose that's an option, although changing how we handle file:/// URLs
> > makes me nervous.  We'd also lose the neat correspondence with sftp:// URLs,
> > which AIUI don't expand ~mbp, just ~.
> 
> But we're already going to have a difference between ssh and sftp
> URLs, which one would otherwise expect to be more similar.  Anyhow it
> certainly seems possible that an sftp server would handle ~mbp.

Launchpad's sftp server already does... by having all sftp sessions start in
virtual /, and putting ~user directories in that /.  ;)

Perhaps bzr serve could call expanduser on its --directory argument.  We
could consider having bzr+ssh URLs pass through the entire first path
segment to --directory if the first path segment startswith ~, so that
bzr+ssh://host/~foo/bar would end up invoking --directory=~foo.  My
suspicion is that that feature wouldn't get much use, but I might be wrong.

-Andrew.