Not trusting file .hg/hgrc from untrusted user root, group dev

Question

The repository is owned by user root, and group dev

Another user is running hg update on the repository and getting the following messages:

Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file .hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
Not trusting file /dev/.hg/hgrc from untrusted user root, group dev
abort: Permission denied: /dev/src/backend/java/com/tt/afr/schedule/service/ScheduleComparator.java

In /etc/mercurial/hgrc, we have:

trusted.users=root

In the home directory of user running hg update, we have this hgrc file:

[trusted]
users = root
groups = dev

User is connecting to server using ssh and running the commands.

What can we do to fix this?

Apennines

You do know that /dev is used for other things, right? – Bozcaada

It's not actually dev, it's our app name, i only changed it in the question. Silly of me to forget that dev is used for other things. – Apennines

Answer 1

Please read the help on trust in Mercurial and make sure that you've added the trust settings on the server. When you connect over SSH, it does not matter who you trust or don't trust locally — it's the hg binary that you run on the server (via the SSH tunnel) that needs to trust the config file.

Also note that you need to put

[trusted]
users = root

in the /etc/mercurial/hgrc file on the server. The section.key = name syntax we use when talking about configuration settings only work on the command line.

Deianira

From the article you linked: Set trusted.users=root in /etc/mercurial/hgrc, and then have your repository's hgrc owned by root. – Apennines

Yes, but understand that foo.bar=baz is what you use on the command line with --config, in a configuration file you need to use normal ini-file syntax: [foo] bar = baz instead. – Deianira

I've just updated the wiki page to use the right syntax for the config file, I hope that helps! – Deianira

You're right, that worked. Silly of me to think hgrc files would have different syntaxes(syntice?) at different locations. – Apennines

No problem! I can see why the wiki page was confusing, so I fixed the page :-) – Deianira

The link does not work! Must be mercurial-scm.org/wiki/Trust or something other. – Gulp

I still find this confusing, so I'll note that (contrary to my expectation from reading this answer and the wiki) my case was fixed by making the change in my local ~/.hgrc. I was trying a log -R /path/to/repo, and getting "not trusting file /eng/apt/repo/apt/.hg/hgrc from untrusted user 1234, group 5678". When I added [trusted] users = 1234 to my ~/.hgrc, the warning went away. – Kokoschka

chmod g+s -R mydir to make group name sticky so new files keep group – Coelho

Answer 2

For everybody else who has added this solution to their /repo/.hg/hgrc and nothing happened, this solution worked for me: https://j.ee.washington.edu/trac/gmtk/ticket/33

Add in /etc/mercurial/hgrc.d/trust.rc

[trusted]
groups = yourgroup
users = youruser

Essentially, writing permissions to /repo/.hg/hgrc will not work, because the file itself is owned by an untrusted user.

Tybi

Your solution is very useful for OpenBSD. There is a special path /etc/mercurial/hgrc.d and file /etc/mercurial/hgrc.d/openbsd-security.rc. – Googolplex

Answer 3

Based on the answer by DustWolf, this works on Ubuntu under WSL (Windows Subsystem for Linux) using a Windows drive letter share mounted using Microsoft's WSL drvfs file system driver, i.e., hg running locally on a shared drive.

not trusting file /mnt/x/repo/.hg/hgrc from untrusted user root, group root
Mercurial Distributed SCM (version 5.3.1)
(see https://mercurial-scm.org for more information)

Copyright (C) 2005-2020 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Create trust.rc on the WSL machine:

sudo touch /etc/mercurial/hgrc.d/trust.rc
sudo nano /etc/mercurial/hgrc.d/trust.rc

Add:

[trusted]
groups = root
users = root

Save trust.rc and hg should now trust the repo hgrc as WSL's drvfs driver mounts the share as root:root.

wsl wsl-drvfs

Moffat

Answer 4

Not your case, but might be worth a hint:

I had this error in a local container that was setup to migrate repos from hg to GitLab. Solved it by just by changing the ownership of the .hg directory in the downloaded hg's repository folder to root user/group:

chown -R root:root .hg

And the message not trusting file /data/hg-repo/.hg/hgrc from untrusted user 1000, group 1000 was gone.

Amaleta