Please check comm-beta permissions

RESOLVED FIXED

Status

Developer Services
General
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: rail, Unassigned)

Tracking

Details

(Reporter)

Description

5 years ago
I cloned a repo (ssh hg.mozilla.org clone comm-beta /releases/comm-beta) and can't push to the repo using a different user (ffxbld-stage, scm_level_1):

pushing to ssh://hg.mozilla.org/users/raliiev_mozilla.com/comm-beta
searching for changes
remote: not trusting file /repo/hg/mozilla/users/raliiev_mozilla.com/comm-beta/.hg/hgrc from untrusted user raliiev@mozilla.com, group scm_level_1
remote: not trusting file /repo/hg/mozilla/users/raliiev_mozilla.com/comm-beta/.hg/hgrc from untrusted user raliiev@mozilla.com, group scm_level_1
remote: adding changesets
remote: abort: Permission denied: /repo/hg/mozilla/users/raliiev_mozilla.com/comm-beta/.hg/store/00changelog.i
abort: unexpected response: empty string

It works fine for users/raliiev_mozilla.com/mozilla-beta.
Can you check the original comm-* repos for any weird bits being set as well please? I'm wondering if there's something wrong in those that have caused this.
(Reporter)

Comment 2

5 years ago
I ended up deleting the repo, creating an empty repo and pushing from my laptop. It worked OK. It would be great to check the permissions of the original repos though.
Summary: Please fix users/raliiev_mozilla.com/comm-beta permissions → Please check comm-beta permissions
(Reporter)

Comment 3

4 years ago
this applies to mozilla-beta clones too
The original repos appear fine; the script is doing a straight hg clone of them and then applying permission changes, so I'd suspect something in that process. Do you have a recent example of this that I can go poke at, or can you reproduce at will?
(Reporter)

Comment 5

4 years ago
Not anymore. You can try to reproduce this by cloning repos to your user repo by:

 ssh hg.mozilla.org clone mozilla-beta /releases/mozilla-beta
 or
 ssh hg.mozilla.org clone comm-beta /releases/comm-beta
hg.mozilla.org/users/catlee_mozilla.com/ach is suffering from this right now
(In reply to Rail Aliiev [:rail] from comment #5)
> Not anymore. You can try to reproduce this by cloning repos to your user
> repo by:
> 
>  ssh hg.mozilla.org clone mozilla-beta /releases/mozilla-beta
>  or
>  ssh hg.mozilla.org clone comm-beta /releases/comm-beta

Sure, but I don't have another user ID with which I can push to it. I've done the clone and there are no apparent differences besides scm_level. Hm, I cleaned up I bunch of broken pushlogs recently; perhaps that was the problem, despite 00changelog.i being called out above. 

:catlee, your repo definitely has wrong permissions; it's a mix of scm_level_1 and scm_l10n. In fact, it looks like most/all of your l10n clones are b0rked. Have you cloned any recently?
> :catlee, your repo definitely has wrong permissions; it's a mix of
> scm_level_1 and scm_l10n. In fact, it looks like most/all of your l10n
> clones are b0rked. Have you cloned any recently?

Yes, they were all freshly cloned yesterday via something like this:
ssh hg.mozilla.org edit $l delete YES
ssh hg.mozilla.org clone $l releases/l10n/mozilla-beta/$l
Same issue on http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/ too.


mtabara@localhost:[]~/work/moz/ash-mozharness$ hg push -f ssh://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/
pushing to ssh://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness/
remote: not trusting file /repo/hg/mozilla/users/asasaki_mozilla.com/ash-mozharness/.hg/hgrc from untrusted user asasaki@mozilla.com, group scm_level_1
remote: not trusting file /repo/hg/mozilla/users/asasaki_mozilla.com/ash-mozharness/.hg/hgrc from untrusted user asasaki@mozilla.com, group scm_level_1
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: transaction abort!
remote: rollback completed
remote: abort: Permission denied: /repo/hg/mozilla/users/asasaki_mozilla.com/ash-mozharness/.hg/store/data/configs/android/android__panda__releng.py.i
abort: unexpected response: empty string

Updated

4 years ago
Depends on: 930012
The root of the problem was that the hg clone was using hardlinks, so if a user had write access to a file being cloned (e.g. had scm_l10n privs and cloned a l10n repo), hg would link to the file instead of using the normal pull protocol. The cloning process now forces --pull, so we shouldn't run into any *new* instances of this. There are probably existing repos that are b0rked, though.

Any pushes to either the user or source repo would break the hard link, though, which is what's happened in :mtabara's case. I've fixed what I can; if someone pushes to the source repo you may run into other cases of this, in which case open a bug (or reopen this one).
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Component: WebOps: Source Control → General
Product: Infrastructure & Operations → Developer Services
You need to log in before you can comment on or make changes to this bug.