Page MenuHomePhabricator

Peculiar Authorization Issue in cloned repositories
Closed, InvalidPublic

Description

We had 2 repositories CCode and VCode, VCode was visible to me CCode to everyone else. When a differential I commandeered from someone else got closed by him. He got the notifications but could not access the differential. The only way to fix this was to give visible permissions to VCode.

Note: I did a clone of Code because after the migration I could not see any of the commits at Code and my first thought was that the database was corrupt.

Event Timeline

elastinuno raised the priority of this task from to Needs Triage.
elastinuno updated the task description. (Show Details)
elastinuno added a subscriber: elastinuno.

Tasks are in Maniphest and are not "Commandeer"-able. Diffs in Differential are. Which are you talking about? Can you follow the bug reporting guide and list out a specific set of steps to reproduce?

https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#reproducibility

Thanks @chad for the warning. This is how I found the bug.

To reproduce:

  • create 2 different users
    • nuno, andy
    • add both users to a project code
  • create 2 clones of the same repository
    • name the first CODE
      • add visible to project code
    • name the second CODEV
      • add visible to nuno
    • create a diff for andy
    • make nuno commandeer the diff
    • make andy user push the commit
      • to do this I pulled the patch from diff with arc patch DXX --no-branch
      • changed the bookmark
      • then pushed to the mercurial repository` hg push`

Now andy does not have access to the DXX and can have some pending notifications that cant be closed the patch is both applied to CODE and CODEV and there are some permission issues associated with it.

I think the issue is revision DXX is associated with or becomes associated with CODEV, which then means user andy can't see it. Worth calling out when you run commands like hg push you bypass policy settings that something like arc land should enforce.

Thanks @chad for the warning. This is how I found the bug.

To reproduce:

  • create 2 different users
    • nuno, andy
    • add both users to a project code
  • create 2 clones of the same repository
    • name the first CODE
      • add visible to project code
    • name the second CODEV
      • add visible to nuno
    • create a diff for andy

I assume you made a revision via arc diff what the user andy. What repository is this revision against at this time? If andy was able to make it against CODEV via arc diff I think that's a policy bug, since andy can't see that repository.

  • make nuno commandeer the diff
  • make andy user push the commit
    • to do this I pulled the patch from diff with arc patch DXX --no-branch
    • changed the bookmark
    • then pushed to the mercurial repository` hg push`

Now andy does not have access to the DXX and can have some pending notifications that cant be closed the patch is both applied to CODE and CODEV and there are some permission issues associated with it.

What repository is DXX associated with?

I don't think we want to start mapping revisions 1 : many with repositories; it seems like there's a lot of nice assumptions we can make around a 1 revision to 1 repository model.

I assume you made a revision via arc diff what the user andy. What repository is this revision against at this time? If andy was ?>able to make it against CODEV via arc diff I think that's a policy bug, since andy can't see that repository.

Hum, didn't thought of this but at this time the revision was just at CODE

What repository is DXX associated with?

To just CODE

So CODEV is not associated with DXX in any way and yet the user andy can only access DXX if given access to CODEV?

This is not how policies work. You should see CODEV somehow someway associated with DXX...

epriestley added a subscriber: epriestley.

I suspect this isn't a bug -- diffs have repository associations, and you must be able to see a repository to see associated diffs. You must be able to see the active diff to see a revision. So andy caused the active diff to belong to a repository that nuno can not see, which prevents nuno from seeing the revision.

Basically, if you looked at the revision, you'd see some code from CODEV (the active diff has code from CODEV). nuno is not allowed to see anything from CODEV, so he isn't allowed to see the revision.

In any case, we haven't seen more reports of this in more than a year and if this is a bug it may be resolved by T10748. If anyone else is still seeing issues after that finishes up, feel free to file a new report describing what you're running into.