>> This is caused by bzr not really supporting to be run under sudo. In config.py:ensure_config_dir_exists it creates $HOME/.bazaar without dropping rights to the $SUDO_USER. Unfortunately the same could be said for all other config-writing functions. I'm not exactly sure where (and how) it would be best to fix that.
This would be possible. However, it also seems likely to break in the case that you do "sudo -H bzr" and actually _want_ bzr to use root's configuration.
It may be that we create ~/.bazaar even when we don't need to, and trimming that would make it similar to #12. However the problem may still occur with ~/.bzr.log.
Another option would be to say we always attempt to chown the .bazaar (and .bzr.log) to be the same as the containing directory. That is perhaps not quite unixy, but it seems correct for the main cases: with HOME=/root it's owned by root, with HOME=/home/mbp by me. It's a bit like a setgid directory.
Thierry's comment in #1 is interesting:
>> This is caused by bzr not really supporting to be run under sudo. In config. py:ensure_ config_ dir_exists it creates $HOME/.bazaar without dropping rights to the $SUDO_USER. Unfortunately the same could be said for all other config-writing functions. I'm not exactly sure where (and how) it would be best to fix that.
This would be possible. However, it also seems likely to break in the case that you do "sudo -H bzr" and actually _want_ bzr to use root's configuration.
It may be that we create ~/.bazaar even when we don't need to, and trimming that would make it similar to #12. However the problem may still occur with ~/.bzr.log.
Another option would be to say we always attempt to chown the .bazaar (and .bzr.log) to be the same as the containing directory. That is perhaps not quite unixy, but it seems correct for the main cases: with HOME=/root it's owned by root, with HOME=/home/mbp by me. It's a bit like a setgid directory.