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: https://github.com/sassoftware/.
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 safe.directory /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 safe.directory /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)
And
To add an exception for this directory, call:
git config --global --add safe.directory /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:
[safe]
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.
