permissions problems on sftp repo [SOLVED]

[Thomas Nichols]

Excellent, thanks Mattias. For the record, the following works well for me:

 * use bzr+ssh:// protocol
 * use  the setgid bit on directories so that new files are created with 
the group of the parent directory

To achieve this:

$ chmod -R 0000 .bzr
$ find .bzr -type d -exec chmod 2770 {} \;
$ find .bzr -type f -exec chmod 0660 {} \;

Now, after I commit as user thomasn (where thomasn has default group 
'users' and also belongs to group 'carriebot') I get

# ls -la .bzr/branch
total 24
drwsrws--- 3 carriebot carriebot 4096 Mar 10 12:56 .
drwxrws--- 6 carriebot carriebot 4096 Feb  2 21:32 ..
-rw-rw---- 1 carriebot carriebot   65 Feb  3 00:32 branch.conf
-rw-rw---- 1 carriebot carriebot   34 Feb  2 21:32 format
-rw-rw---- 1 thomasn   carriebot   54 Mar 10 12:56 last-revision
drwsrws--- 2 carriebot carriebot 4096 Mar 10 12:56 lock
-rw-rw---- 1 carriebot carriebot    0 Feb  2 21:32 tags

So now my question is: why is this not the default action of bzr init? 
This seems like a compelling reason to have bzr init create .bzr with 
chmod g+s -- are there any reasons why this should not be changed? 
Though it has been most instructive for me, I'm guessing many bzr users 
will not want to learn about setgid/setuid behaviour as it applies to 
files and directories on different Unices... just in order to allow 
users to commit from their local boxes without mashing the repo ;-)

-- Thomas.




Mattias Eriksson wrote on 2008/03/09 8:53:
> you must do chmod g+s sites/elk to preserver the group ownership.
> However, the openssh daemon will not respect this so the sftp://
> protocol will not work, the bzr+ssh protocol handles this correctly.
>
> //Mattias
>
>
> lör 2008-03-08 klockan 22:16 +0000 skrev Thomas Nichols:
>
>   
>> Hi,
>>
>> I'm moving a bunch of projects from svn to bzr, and really like it -- 
>> but have a permissions problem.
>>
>> I set the repo to be g+w on everything -- and I have a cron script that 
>> commits to this repo as user carriebot group carriebot, these being the 
>> user and group who own all files in the repo. All works sweetly, until I 
>> make a change to the repo from my dev machine, committing to the server as
>> thomasn:users
>>
>> User thomasn on the server is in the carriebot group, so can write to 
>> the repo -- but the _default_ group for thomasn is 'users', and when I 
>> commit from my dev machine over ssh to the server I get the following in 
>> the server repo:
>>
>> # ls -la sites/elk/.bzr/branch
>> total 24
>> drwxrwx--- 3 carriebot carriebot 4096 Mar  8 21:50 .
>> drwxrwx--- 6 carriebot carriebot 4096 Feb  2 21:32 ..
>> -rwxrwx--- 1 carriebot carriebot   65 Feb  3 00:32 branch.conf
>> -rwxrwx--- 1 carriebot carriebot   34 Feb  2 21:32 format
>> -rw-rw---- 1 thomasn   users       54 Mar  8 21:50 last-revision
>> drwxrwx--- 2 carriebot carriebot 4096 Mar  8 21:50 lock
>> -rwxrwx--- 1 carriebot carriebot    0 Feb  2 21:32 tags
>>
>> ... so .bzr/branch/last-revision is now owned by thomasn:users, and 
>> (unsurprisingly) the cron scripts can no longer use the repo.
>>
>> I've tried using both sftp:// and bzr+ssh:// protocols, same issue.
>>
>>
>> How are other people tackling this? Is there a daemon bzr-server I could 
>> leave running, so that thomasn:users could issue client requests to this 
>> server (and the server process would be the only one making filesystem 
>> changes to the repo)? Is the only solution to commit from my dev box as 
>> user carriebot? Or is this workflow better supported by a different 
>> approach?
>>
>> Any suggestions would be most welcome.
>>
>> Regards,
>> Thomas.
>>
>>     
>
>