BookmarkSubscribeRSS Feed

What to do when Git reports Fatal: Unsafe Repository

Started ‎04-20-2022 by
Modified ‎05-03-2022 by
Views 27,749

Earlier this month - April 2022 - Git released an update (2.35.2) to fix a security vulnerability. The problem was that on multi-user systems (not only Windows hosts) where git projects could exist down in a directory structure, the owner of the parent directory might implement configurations which granted them access and privileges to git files that they're not supposed to have. The fix was to add some additional configuration parameters to help manage the access allowed - as well as new default behavior to enforce it. You can read more about the vulnerability (reported as CVE-2022-24765) as well as the fixes in Github's blog post, Git Security Vulnerability Announced.


That new default behavior to enforce the new access controls might impact your ability to run certain SAS-provided deployment projects which are normally shared using git technology. In particular, we've seen challenges recently with the viya4-deployment project where it stumbled across git's new enforcement behavior. This blog post will explain what went wrong and how it can be easily addressed.


Getting Started


We highly recommend using SAS provided projects to provision infrastructure (Infrastructure as Code) and automate deployment of SAS Viya software (Deployment as Code). Those projects - and many others - can be found at Github:


Both of those projects can be used in a couple of ways, either as a code repository for use interactively with local utilities (like Ansible, cloud-provider CLI tools, etc.) --or-- they can be built into standalone Docker containers with those utilities baked in (so you don't have to install them and their dependencies).


For the purposes of this blog post, we're focused on the latter approach - that is running the viya4-deployment as a Docker container to install SAS Viya software.  

The Problem


Just last week, we saw where we were able to run the IaC project code (i.e. viya4-iac-aws) just fine. But then when we tried running the DaC project code (i.e. viya4-deployment), it ran for a while, but then hit a snag after defining some NFS storage, complaining:


	TASK [vdm : command] ******************************************************************************************************************************
	fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["git", "log", "-1", "--format=format:%H"], "delta": "0:00:00.006522", "end": "2022-04-18 19:32:09.612864", "failed_when_result": true, "msg": "non-zero return code", "rc": 128, "start": "2022-04-18 19:32:09.606342", "stderr": "fatal: unsafe repository ('/viya4-deployment' is owned by someone else)\nTo add an exception for this directory, call:\n\n\tgit config --global --add /viya4-deployment", "stderr_lines": ["fatal: unsafe repository ('/viya4-deployment' is owned by someone else)", "To add an exception for this directory, call:", "", "\tgit config --global --add /viya4-deployment"], "stdout": "", "stdout_lines": []}


As per usual with Ansible output, it's all encoded but if you look closely you can make out the relevant messages saying:


	fatal: unsafe repository ('/viya4-deployment' is owned by someone else)



	To add an exception for this directory, call:
	    git config --global --add /viya4-deployment


So while unexpected, it's actually a really great error message - and it provides a hint at the solution!  


The Suggested Solution


First, we'll look at the error message's suggested solution to the problem: configure git at the highest level to trust that "/viya4-deployment" can run. Issuing the suggested "git config" command with the "--global" option directs the creation (or modification) of the ".gitconfig" file in the user's $HOME directory to add the following lines:


        directory = /viya4-deployment


After doing that - and then attempting to re-run the viya4-deployment container - we still get the same error message. And that's because the user's $HOME directory isn't included in the viya4-deployment container. We need to get that file into the container. There are a couple of ways to do that...  


№ 1 - Copy, (Re-)Build, and Re-run


Basically, let's just copy the ".gitconfig" file into the viya4-deployment directory:


cp $HOME/.gitconfig    /path/to/viya4-deployment         
# or mv, if preferred


Then (re-)build the viya4-deployment container to pick up the new file, similar to:


cd /path/to/viya4-deployment
docker build -t viya4-deployment .


And now we can try re-running the deployment.  


№ 2 - Mount the file inside the container and Re-run


Docker provides a lot of flexibility to manage the operating environment of containers it runs. One thing you can do is mount external files (or directories) so that the container programs can find and use them. We'll do that here using the "--volume" directive:


docker container run -it --volume $HOME/.gitconfig:/viya4-deployment/.gitconfig \
{{ lots of other directives, too }}  viya4-deployment "baseline,viya,install"
# abbreviated docker run command for clarity ;-)


With this approach we don't need to copy the ".gitconfig" file, and rebuild the viya4-deployment container - we're directly linking the desired file into the container runtime so it's already available when the deployment process runs.  


Suggested, but not really recommended


So, this approach to create (or modify) a top-level git configuration file is suggested by git itself. And it works. But I don't like it, because for the viya4-deployment project, we've chosen to run it as a container - not simply use it as a code repository. The point is, that safe path "/viya4-deployment" is only valid when referenced inside the container runtime. That path is not appropriate for use at the host OS level (unless that's literally where the project repo has been placed - unlikely). So it's a little confusing.  


The Recommended Solution


There's another approach recommended by the git team that we can use and that doesn't require creating files, copying them, and trying to understand what they're meant to be used for in a certain context.


We can define an environment variable that tells git the top-level it should look up to for additional configuration: GIT_CEILING_DIRECTORIES. This variable was made to prevent git from chdir'ing up looking for additional configuration options, especially into slow network-based mounts. But we can use it here to address this recent security vulnerability, too.


Declaring an environment variable into our container runtime is pretty easy - it's just another command-line directive referenced by "--env":


docker container run -it --env GIT_CEILING_DIRECTORIES=/viya4-deployment \
{{ lots of other directives, too }}  viya4-deployment "baseline,viya,install"
# abbreviated docker run command for clarity ;-)


I like this approach much more. We can inject environment variables into the container runtime without rebuilding the container. And even better, if you're using the viya4-deployment as a code repository instead of as a container runtime, you can set the env var normally at the OS level with a path that makes sense for that use context.  


Don't Do This - It Won't Work


Refer back to the initial suggested approach to create a global ".gitconfig" file (in your user's $HOME directory). If you drop the "--global" directive, then the configuration change will be applied to the current working directory's ".git/config" file. In other words, instead of trying to make the change at a higher directory level (where you might not have permissions), this would try to keep the security configuration local to just this one repo. Unfortunately, in our testing, it doesn't work. The recommended solution to set an environment variable is still the easiest way to localize the change - and doesn't require creating files, managing permissions, etc.  


Find more articles from SAS Global Enablement and Learning here.


It's work Recommended Solution

Version history
Last update:
‎05-03-2022 01:18 PM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started