-
Bug
-
Resolution: Not a bug
-
Medium
-
None
-
5.2.3, 5.12.0, 5.15.0
-
6
-
Severity 3 - Minor
-
28
-
Summary
The repository can be cloned using the URL path after the repository have been renamed with a different name.
Restarting Bitbucket Server and clearing the cache does not help.
Steps to Reproduce
Scenario 1
- Create a repository name original on Bitbucket Server.
- Perform a clone on the client machine.
- Rename the repository from original to new on Bitbucket Server.
- Remove the local repository original on the client machine.
- Perform the clone for original -> Successful
- Perform the clone for new -> Successful
Scenario 2
- Create a repository name original on Bitbucket Server.
- Rename the repository from original to new on Bitbucket Server.
- Perform the clone for original -> Successful
- Perform the clone for new -> Successful
Expected Results
Run in a warning message to indicating the repository does not exist:
$ git clone http://admin@localhost:7990/scm/ren/original.git Cloning into 'original'... Password for 'http://admin@localhost:7990': fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it.
Actual Results
The clone of the renamed repository is successful:
$ git clone http://localhost:7990/scm/ren/original.git Cloning into 'original'...
Workaround
n/A
- relates to
-
BSERV-3751 Allow historical aliasing of projects and repositories
- Closed
-
- Gathering Interest
- mentioned in
-
Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-11048] Repository available for clone after renaming
The repository aliasing that was introduced by BSERV-3751 is the cause of this problem. The aliasing seems to be isolated to two DB tables, bb_project_alias (if a project key is renamed) and bb_repository_alias (if a repository is renamed and/or moved into another project). After clearing the contents of these tables, the repositories can no longer be cloned from the original URLs. There do not appear to be any side-effects from deleting this content.
As a more permanent workaround, a scheduled event could be added to the database to keep the affected tables empty. E.g. for MySQL:
SET GLOBAL event_scheduler = ON;
use stash;
create event remove_repo_aliases
on schedule
every 1 minute
do
delete from bb_repository_alias;
create event remove_project_aliases
on schedule
every 1 minute
do
delete from bb_project_alias;
- If the moved repository has a set of permissions applied on it already, they will be carried to the new project too.
- The source project permissions do not matter since after the move, the effective permissions will be a combination of the repository permissions and the target project permissions.
We arrive at these conclusions based on the following tests.
Tests performed:
Requirements:
- Create two projects Keys: PRJ1 and PRJ2
- Create a repository named new_repo under PRJ1 on Bitbucket Server.
Scenario 1: Move to a new Project
- Access Rights for the user:
- Project level: none
- Repository Level: Read
- Perform a clone of new_repo on the client machine. -> Successful
- Move the repository from PRJ1 to PRJ2 on Bitbucket Server.
- Remove the local repository original on the client machine.
- Perform the clone for new_repo with old URL -> Successful
- Perform the clone for new_repo with new URL -> Successful
> git clone http://test@localhost:25160/b5160/scm/PRJ1/new_repo.git Cloning into 'new_repo'... remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (3/3), done. remote: Total 7 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. > rm -rf new_repo > git clone http://test@localhost:25160/b5160/scm/PRJ1/new_repo.git Cloning into 'new_repo_renamed'... remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (3/3), done. remote: Total 7 (delta 1), reused 0 (delta 0) > git clone http://test@localhost:25160/b5160/scm/PRJ2/new_repo.git Cloning into 'new_repo'... remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (3/3), done. remote: Total 7 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (7/7), done.
Scenario 2: Move and then remove Repository access right
- Access Rights for the user:
- Project level: none
- Repository Level: Read
- Perform a clone of new_repo on the client machine. -> Successful
- Remove the Repository level Access Right.
- Move the repository from PRJ1 to PRJ2 on Bitbucket Server.
- Perform the clone using the original URL -> Unuccessful
- Perform the clone using the new URL -> Unuccessful
> git clone http://test@localhost:25160/b5160/scm/PRJ1/new_repo.git Cloning into 'new_repo'... fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it. > git clone http://test@localhost:25160/b5160/scm/PRJ2/new_repo.git Cloning into 'new_repo'... fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it.
Scenario 3:
- Access Rights for the user:
- Project level: PRJ1 - Read, PRJ2 - none
- Repository Level: none
- Perform a clone of new_repo on the client machine.
- Move the repository from PRJ1 to PRJ2 on Bitbucket Server.
- Perform the clone using the original URL -> Unsuccessful
- Perform the clone using the new URL -> Unsuccessful
> git clone http://test@localhost:25160/b5160/scm/PRJ1/new_repo.git Cloning into 'new_repo'... fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it. > git clone http://test@localhost:25160/b5160/scm/PRJ2/new_repo.git Cloning into 'new_repo'... fatal: remote error: Repository not found The requested repository does not exist, or you do not have permission to access it.
Just to clear the permission complexity, the below table shows the effective permission for a user in the different levels:
| Project | Repository | Effective Permission |
|---|---|---|
| None | None | None |
| None | Read | Read |
| Read | Read | Read |
| Read | None | Read |
Please check the Permissions Matrix for more of such combinations.
Perfect description of the problem @bannamalai!
I can add that the same occurs when a repository is moved from one project to another.
I need a work-a-round to prevent this on a number of repositories. This because the repository is moved to a project that have different access settings. But the original path let the user in via the old original project security settings.
(Can I change something in the DB or in a file on the server?)
This is expected behaviour as the result of repository aliasing. We are tracking a suggestion (BSERV-10230) for allowing users to choose whether or not a repository is aliased after being moved.