CODEWITHSUNDEEP
gitsshgitlab
Jake Mullins
Jake Mullins

Reputation: 61

git push/pull over ssh to locally hosted gitlab as root requires git@gitlab password

I started fighting this problem in this question. I split it off because I realized that it was a different issue that doesn't involve gitpython, but rather git alone.

I have a python script that involves pushing and pulling to a local gitlab instance that must be run as root. The .git/config looks like this:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = [email protected]:my-name/repo-name.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

I have discovered that whenever I run a git pull or git clone as root from gitlab, it requires the [email protected] password as if it was ssh-ing into the host. As you can see in the remote url, all remote operations are done over ssh protocol, not https.

Is this a configuration issue with gitlab? Something I don't know about git or ssh? I must run this script as sudo, so for now I'm working on a way to run the git pull not as root.

Another note for people with similar issues and are seeing error: cannot open .git/FETCH_HEAD: Permission denied while not running as sudo, either delete .git/FETCH_HEAD or change it's ownership away from root and it should execute as normal. This is because git pull involves git fetch, but as it is not successful, it leaves behind an empty FETCH_HEAD owned by root:root, which can't written to by unprivileged users.

Upvotes: 1

Views: 585

Answers (1)

torek
torek

Reputation: 487865

This has nothing to do with Git or GitLab. It's just the basic way sudo operates on a Unix / Linux system.

These systems have a concept of user identity or UID. Your UID is, at the OS level, a simple integer number. The number zero is reserved for the super user, who may—this depends on a lot of OS options and security features that you can enable individually—have the ability to run roughshod over ordinary user permissions, or not.

Besides the UID, the rest of the system provides concepts like one's home directory. Configuration files—including ~/.ssh/config and ~/.gitconfig—tend to live in the home directory; in fact, ~ here stands in for that directory. (The replacement of ~ with $HOME is done by the shell, not by the OS. Python has os.path.expanduser for this; it emulates the typical shell expansions.)

The ssh command uses your home directory to locate your .ssh/config file and your default .ssh/id_rsa and .ssh/id_rsa.pub files, for instance. So when you, as yourself, run ssh [email protected], ssh is able to "log in" to gitlab.our.instance.name as user git if your personal ssh configuration has the right keys in it.

When you run sudo <command>, the command that's run by sudo is run as the super user, i.e., as UID zero. It's also run with the superuser's home directory as the home directory. So the ssh configuration and keys that are used are those in ~root/.ssh/*, not those in ~jake/.ssh/* or whatever your own personal home directory is.

Aside from that, the commands that are run are running on behalf of uid zero. If uid zero (the "super user") can bypass most normal permissions, that user can create new files such as .git/FETCH_HEAD, even if .git is owned by you and does not give UID zero permission. But when that user does create such a file, the new file is owned by that user, i.e., by root.

The long and short of this is never run anything via sudo if it's at all possible not to do that because doing that bypasses way too many permissions checks (depending on OS configuration and other details) and leaves way too many files owned by the super-user so that only the super-user has permission to do anything with those files, forcing you to continue using sudo in a self-perpetuating dance that makes your system insecure.

I must run this script as sudo ...

That is the problem. Fix that. Set things up so that the script can be run as some ordinary, not-specially-privileged user.

I realize this is a case of "doctor, it hurts when I do this": "well don't do that then" - but that's the answer, really! Don't do that! If you find that, for some terrible reason, you must do that for a nanosecond or two, write something that does it for that nanosecond or two and then transfers ownership back to you and quits and lets you proceed as yourself. Do as little as possible as the super-user, because everything you do here must be triple-checked for security, by a security expert.

Upvotes: 1

Related Questions