Comment 6 for bug 348308

Revision history for this message
John A Meinel (jameinel) wrote :

If I was guessing, I would say the chroot is being set based on the '.bzr/smart' you are posting to. So if your layout is:

repo/branch

Then your initial POST goes to 'http://..../repo/branch/.bzr/smart'

At that point, we can see that we don't have a repository (or maybe we see the repository is 1 level up from a request, etc).

Anyway, we've done things 2 different ways in the past. One is to post:

1) POST http://../repo/branch/.bzr/smart open_repository ..
2) POST http://../repo/.bzr/smart open_repository .

The main difference is whether the "Transport.clone('..')" was changing the base URL that we POST to, or whether it was just something changing the paths transmitted.

My guess is the currentcode is doing (1), and that the chroot is being based on the POST url, which means that the jail is causing us to fail. So at this point we could:

1) Change the client to go back to the old way, and have 'clone(..)' change the POST url. I think Andrew didn't like that form. I *think* because there was no guarantee that both URLs were valid to POST to, and we know we have something valid where we are at now.
2) Change the jail code to only jail at the level of config, rather than making it dynamic based on the POST location. I personally would be fine with this, considering the WSGI codes says "expose paths under /srv/bzr/repo" it seems fine to use that as the chroot jail for all requests.