Git CVE-2022-24765 and `safe.directory` Exceptions with Multiple Users about capistrano HOT 6 CLOSED

It seems like the "fix" here would be to introduce a new step for the git SCM to proactively git config --global --add safe.directory {{repo_path}} and run that before the git:clone step.

from capistrano.

This appears to "fix" the issue (creating a new git.rake step and having the local deploy configuration use it):

# lib/capistrano/tasks/git.rake

namespace :git do
  desc 'Identify the mirrored repo as being safe for multi-user access'
  task share_repo: :'git:wrapper' do
    on release_roles(:all), in: :groups, limit: fetch(:git_max_concurrent_connections), wait: fetch(:git_wait_interval) do
      with fetch(:git_environmental_variables) do
        execute :git, 'config', '--global', '--add', 'safe.directory', Shellwords.escape(repo_path)
      end
    end
  end
end

# config/deploy.rb

before 'git:clone', 'git:share_repo'

The same command run above successfully completes rather than erroring out:

00:00 git:wrapper
      01 mkdir -p /tmp
    ✔ 01 server1 0.212s
      Uploading /tmp/git-ssh-32a823a99eb59909b56b.sh 100.0%
      02 chmod 700 /tmp/git-ssh-32a823a99eb59909b56b.sh
    ✔ 02 server1 0.214s
00:00 git:share_repo
      01 git config --global --add safe.directory /srv/app/repo
    ✔ 01 server1 0.212s
00:01 git:clone
      The repository mirror is at /srv/app/repo
00:01 git:update
      01 git remote set-url origin [email protected]:org/app.git
    ✔ 01 server1 0.222s
      02 git remote update --prune
    ✔ 02 server1 2.710s

And this has the side-effect of creating a ~/.gitconfig for the deploying user containing:

[safe]
        directory = /srv/app/repo

from capistrano.

Although this has the downside of continually appending that directory = /srv/app/repo safe entry to the ~/.gitconfig with every subsequent release. 😉

from capistrano.

Hmm. This one is a bit tricky.

Is this something that Capistrano can/should solve? It feels more like a provisioning step. In other words, the sysadmin/script that is creating the user accounts on the host would be responsible for setting up permissions, and this would include the git safe directory setting.

I feel like this is an edge case and is fairly adequately addressed by the error message printed in the logs, which explains exactly what needs to be done to proceed:

      01 git remote set-url origin [email protected]:org/app.git
      01 fatal: detected dubious ownership in repository at '/srv/app/repo'
      01 To add an exception for this directory, call:
      01
      01        git config --global --add safe.directory /srv/app/repo

What do you think?

Alternatively, Capistrano could rescue from this error and call git config ... itself in response to this condition. That way it would only be done once, and only if needed.

However, I feel that automating a response to a security warning might be crossing a line. Are we defeating the purpose of this security check if Capistrano automates around it without user action?

from capistrano.

Hey @mattbrictson, firstly thanks for replying and for your work on the project.

I could certainly go either way on it.

Having done most of the DevOps for many projects, I've found that one of the niceties of Capistrano from a provisioning standpoint is that I can have an automated system (like Ansible, Puppet, Chef, etc.) create a single, base location for application deployment (like /srv/app, for example). During that process, I can set ownership and permissions to allow that shared location to be group writable (i.e. chown deploy:deploy /srv/app && chmod 2775 /srv/app). Then, I can give "permission" to system users to deploy by adding them to the deploy location's ownership group.

Given that, everything else (outside of maybe shared files) is basically hands-off from a DevOps standpoint. Capistrano does whatever it needs to do in that directory. Capistrano creates the revisions directories, writes the releases log, manages the current release symlink, etc. And with that, if the app is configured to deploy via git clone, then it clones and makes a repo directory as part of the Capistrano::SCM::Git process (/app/srv/repo by default, see repo_path).

Could DevOps create that /app/srv/repo? Sure, but it'll require that and the addition of explicit Capistrano configurations to lock the checkout location to /app/srv/repo. If Capistrano no longer fully manages that directory, then relying on defaults would eventually bite.

In this case, if feels like because Capistano's SCM logic creates the local repository, then it should be Capistrano's SCM logic to properly configure it for use. But that's just my opinion, certainly.

from capistrano.

Given we both could go either way on this one, I am going to resolve this as "won't fix" for now. I don't have experience with multi-user capistrano deployments, so I am not 100% comfortable making changes (and supporting them) in this area. This gem is very lightly maintained at this point and I want to avoid changes that introduce regressions or unintended side effects.

from capistrano.