Execute Linguist fail due to repository owner permission when running in Docker

[vovikhangcdv]

Describe the bug

I build up an Dockerfile to install and run Linguist from ubuntu:20.04 image. But when I run the docker, I got the error message:

/var/lib/gems/2.7.0/gems/github-linguist-7.20.0/bin/github-linguist:48:in `new': repository path '/tmp/' is not owned by current user (Rugged::ConfigError)
        from /var/lib/gems/2.7.0/gems/github-linguist-7.20.0/bin/github-linguist:48:in `github_linguist'
        from /var/lib/gems/2.7.0/gems/github-linguist-7.20.0/bin/github-linguist:142:in `<top (required)>'
        from /usr/local/bin/github-linguist:23:in `load'
        from /usr/local/bin/github-linguist:23:in `<main>'

This is my Dockerfile

FROM ubuntu:20.04 AS codeql_base
LABEL maintainer="Github codeql team"


ENV DEBIAN_FRONTEND=noninteractive

# Set up the enviroment
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
    	g++ \
    	make


# Install Linguist
RUN apt-get install -y cmake pkg-config libicu-dev zlib1g-dev libcurl4-openssl-dev libssl-dev ruby-dev
RUN gem install github-linguist

ENTRYPOINT ["github-linguist"]

And this is my run command:

git clone https://github.com/JoyChou93/java-sec-code
cd java-sec-code
docker run --rm -v "$PWD:/tmp" -w "/tmp" doublevkay/linguist

Expected behaviour

Linguist should show the list of repo languages

---

Could someone explains the issue to me? Many thanks!

[lildude]

This has nothing to do with Linguist and is really a Docker permissions issue because your host user that owns the PWD doesn't have the same permissions or isn't the same user (this one in this case) within your container: repository path '/tmp/' is not owned by current user.

You can generally fix this by passing --user $(id -u) to your docker run command.

[fredgan]

Hi @lildude

I mount a NAS server to one directory. Then I use ls command, it shows that all the sub-directories and files is owned by 4294967294:4294967294 or in another way nobody:nobody.

Then I use current root user to execute github-linguist command to stat my github-repo directory which is in my mounted NAS directory.

Traceback (most recent call last):
	4: from /usr/local/bin/github-linguist:23:in `<main>'
	3: from /usr/local/bin/github-linguist:23:in `load'
	2: from /var/lib/gems/2.5.0/gems/github-linguist-7.23.0/bin/github-linguist:142:in `<top (required)>'
	1: from /var/lib/gems/2.5.0/gems/github-linguist-7.23.0/bin/github-linguist:48:in `github_linguist'
/var/lib/gems/2.5.0/gems/github-linguist-7.23.0/bin/github-linguist:48:in `new': repository path '/nas/chaoss/perceval/repositories/https:/github.com/madler/zlib-git/' is not owned by current user (Rugged::ConfigError)

Why cannot my root user execute github-linguist command successfully? Do you have any idea to solve this problem? Thanks

[lildude]

Oooo, so this can get quite complicated and is well beyond the scope of Linguist as it has nothing to do with Linguist and everything to do with how the OS maps users across NFS mounts.

Why cannot my root user execute github-linguist command successfully?

Because root on your client system is not the same user as root on the server. Assuming as such could be dangerous so root requests are mapped to the nobody user by default. This is called "root squashing". You can prevent this by mounting with the no_root_squash option which might do the trick. If not, you're going to need to ensure the users on both sides are the same.

Have a look at the exports man page around user ID mapping.

[fredgan]

@lildude Thanks for your explaination. But I still have a question.

I have another tool, scc, which is used for code line statistics. In the same scene, scc can read the repo and generate the stat output.

So my question is, why linguist cannot read but scc can.

[lildude]

It's not linguist-specificially that is reporting the permissions issue, it's libgit2, indirectly via rugged, which is used to read the git repo.

The ownership requirement was recently tightened to address a security vulnerability as detailed in https://github.blog/2022-04-12-git-security-vulnerability-announced/. To resolve this, you will need to ensure the owner of the files and the user accessing them are the same. Or you can use the safe.directory directive to relax this.