branching in a shared repo doesn't inherit permissions

Bug #403250 reported by Jan Danielsson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

My goal is to set up a shared repository which is read-writable by the testdev group.

Review this shell session:
----------------------------------------
# cat /usr/local/bin/create_shared_bzr_repo.sh
#!/bin/sh

die()
{
        echo "Error: $1" 1>&2
        exit 1
}

if [ $# -lt 2 ]; then
        echo "Usage: $0 <directory> <group>"
        exit 0
fi

[ -d $1 ] && die "Repository directory already exists."

(mkdir -m 755 -p $1 && chown root:$2 $1 && chmod 02770 $1 && \
 bzr init-repo --2a --no-trees $1) || die "Unable to initialize shared repo."

# # /repos is a symlink to /var/bzr
# create_shared_bzr_repo.sh /repos/test testdev
Shared repository (format: 2a)
Location:
  shared repository: /repos/test

# cd /repos
# ls -l
total 3
drwxrws--- 3 root testdev 512 Jul 22 13:58 test
# cd test
# ls -la
total 6
drwxrws--- 3 root testdev 512 Jul 22 13:58 .
drwxr-xr-x 4 root wheel 512 Jul 22 13:58 ..
drwxrws--- 4 root testdev 512 Jul 22 13:58 .bzr
# mkdir dev
# ls -l
total 4
drwxrws--- 4 root testdev 512 Jul 22 13:58 .bzr
drwxr-xr-x 2 root testdev 512 Jul 22 14:02 dev
# # Wrong permissions, so we fix that.
# chmod 2770 dev
# ls -l
total 4
drwxrws--- 4 root testdev 512 Jul 22 13:58 .bzr
drwxrws--- 2 root testdev 512 Jul 22 14:02 dev
# cd dev
# bzr init --2a
Created a repository branch (format: 2a)
Using shared repository: /var/bzr/test/
# ls -la
total 6
drwxrws--- 3 root testdev 512 Jul 22 14:05 .
drwxrws--- 4 root testdev 512 Jul 22 14:02 ..
drwxrws--- 4 root testdev 512 Jul 22 14:05 .bzr
# ls -la .bzr
total 12
drwxrws--- 4 root testdev 512 Jul 22 14:05 .
drwxrws--- 3 root testdev 512 Jul 22 14:05 ..
-rw-rw---- 1 root testdev 141 Jul 22 14:05 README
drwxrws--- 3 root testdev 512 Jul 22 14:05 branch
-rw-rw---- 1 root testdev 35 Jul 22 14:05 branch-format
drwxrws--- 2 root testdev 512 Jul 22 14:05 branch-lock
# # Looks ok!
# cd ..
# pwd
/repos/test
# ls -la
total 8
drwxrws--- 4 root testdev 512 Jul 22 14:02 .
drwxr-xr-x 4 root wheel 512 Jul 22 13:58 ..
drwxrws--- 4 root testdev 512 Jul 22 13:58 .bzr
drwxrws--- 3 root testdev 512 Jul 22 14:05 dev
# bzr branch /repos/test/dev stable
Branched 0 revision(s).
# ls -l
total 6
drwxrws--- 4 root testdev 512 Jul 22 13:58 .bzr
drwxrws--- 3 root testdev 512 Jul 22 14:05 dev
drwxr-xr-x 3 root testdev 512 Jul 22 14:14 stable
# ls -la stable/
total 6
drwxr-xr-x 3 root testdev 512 Jul 22 14:14 .
drwxrws--- 5 root testdev 512 Jul 22 14:14 ..
drwxr-xr-x 4 root testdev 512 Jul 22 14:14 .bzr
# ls -la stable/.bzr
total 12
drwxr-xr-x 4 root testdev 512 Jul 22 14:14 .
drwxr-xr-x 3 root testdev 512 Jul 22 14:14 ..
-rw-r--r-- 1 root testdev 141 Jul 22 14:14 README
drwxr-xr-x 3 root testdev 512 Jul 22 14:14 branch
-rw-r--r-- 1 root testdev 35 Jul 22 14:14 branch-format
drwxr-xr-x 2 root testdev 512 Jul 22 14:14 branch-lock
# # The branch is not group-writable, so it will not work for testdev's.
----------------------------------------

I have written a script which sets the proper permissions of the newly created branch. But this means that each time someone has created a branch in the shared repository, I need to log on to the server as root, and fix the permissions before anyone else can access it. Everything seems to work properly after the permissions have been manually fixed.

What I'm wondering is this: Provided the proper permissions are set on the initial directory, and one runs "bzr init", it appears that all the files and directories inherit the proper permissions. Is there a technical reason the same behavior can't apply to "bzr branch" when the target is within a shared repository?

Using bazaar 1.16.1 on NetBSD/amd64 4.0 and 5.0.

Martin Pool (mbp)
Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.