Analysis and Solutions for Git's "unsafe repository" Error Caused by CVE-2022-24765 Security Update

Technical Background and Problem Analysis

With the release of Git 2.35.2, a significant security update was introduced to fix the CVE-2022-24765 vulnerability. This vulnerability involved a permission validation flaw in Git's handling of cross-user repository access, potentially allowing malicious users to gain unauthorized access through specific operations. As a remediation measure, Git implemented stricter repository security checks, triggering security warnings and blocking operations when detecting a mismatch between the current user and repository owner.

In practical application scenarios, this security mechanism has significantly impacted web server environments. Taking Apache servers as an example, when PHP code executes Git commands through functions like exec() or shell_exec(), Apache typically runs under the www-data user identity. If the target Git repository is owned by another user (such as ubuntu or git), the system throws a fatal error: fatal: unsafe repository ('/home/repon' is owned by someone else).

The core of this error lies in Git's updated security model. Prior to Git 2.35.2, Git allowed any user to access any repository as long as filesystem permissions permitted it. The new security mechanism requires Git to verify whether the current user matches the repository owner or whether the repository has been explicitly marked as "safe." While this change enhances security, it also breaks existing workflows, particularly in automated deployment and continuous integration scenarios.

Detailed Analysis of Solutions

Solution 1: Configuring safe.directory to Trust Directories

The most direct solution is to explicitly trust specific directories through Git configuration. Git provides the safe.directory configuration option, allowing users to add specific paths to a safety list. Executing the following command marks the /home/repon directory as safe:

git config --global --add safe.directory /home/repon

This command adds the following configuration section to the global Git configuration file (typically ~/.gitconfig):

[safe]
    directory = /home/repon

It is important to note that this method should be used cautiously. Adding a directory to the safety list means Git will skip ownership checks for that directory, which may introduce security risks. This approach is recommended only when the directory contents are fully trusted and potential risks are understood.

For scenarios requiring trust in multiple directories, Git version 2.36 introduced wildcard support. The following command can be used to trust all directories:

git config --global --add safe.directory '*'

However, in production environments, this configuration should be avoided as it completely disables Git's security check mechanism.

Solution 2: Executing Commands via sudo with User Switching

Another solution is to maintain Git's security checks but allow the www-data user to execute Git commands as the repository owner through privilege escalation. This can be achieved through sudo configuration:

sudo -u ubuntu -- git status

To enable the www-data user to perform this operation without a password, a configuration file needs to be created in the /etc/sudoers.d/ directory:

www-data ALL=(ubuntu) NOPASSWD: /usr/bin/git

This configuration allows the www-data user to execute the /usr/bin/git command as the ubuntu user without requiring a password. From a security perspective, this approach is preferable to completely disabling security checks, as it preserves Git's security mechanism while addressing the user mismatch issue through permission management.

When implementing this solution, consider the following:

1. Ensure the ubuntu user has appropriate access permissions to the target repository
2. Restrict sudo permissions to only necessary Git commands
3. Regularly audit sudo configurations to prevent over-authorization

Solution 3: Modifying Repository Ownership

If the Git repository is dedicated to web applications, consider changing the repository ownership to the www-data user:

sudo chown -R www-data:www-data /home/repon

This method directly resolves the user mismatch issue since the repository owner becomes the user actually executing Git commands. However, this approach may not be suitable for all scenarios:

• If multiple users need access to the same repository, ownership changes may cause permission conflicts
• In certain development environments, developers may prefer to maintain personal ownership of repositories
• Ownership changes may affect other tools or scripts that depend on the original owner

On Windows systems, this method may encounter additional challenges. Particularly for repositories on removable drives, Git's security check mechanism is stricter, and simple ownership changes may not resolve the issue.

Solution 4: Downgrading Git Version

As a temporary solution, consider downgrading Git to a version prior to 2.35.2. On Ubuntu systems, the following command can be used:

apt install git-man=1:2.17.0-1ubuntu1 git=1:2.17.0-1ubuntu1

While this method can immediately resolve the problem, it carries significant security risks. CVE-2022-24765 is a genuine security vulnerability, and downgrading Git exposes the system to this vulnerability. Therefore, this approach should only be used in emergency situations, with plans to upgrade to a secure version as soon as possible.

Implementation Recommendations and Best Practices

Based on analysis of the above solutions, we recommend the following implementation strategy:

First, evaluate the specific use case. If Git commands are used only for read operations (such as obtaining commit hashes, branch information, etc.) and the execution environment is relatively secure, consider using the safe.directory configuration. However, ensure:

1. Only trust necessary directories, avoiding wildcards
2. Regularly review the safe directory list
3. Implement multi-layer protection combining filesystem permissions

For scenarios requiring write operations or higher security requirements, the sudo solution is recommended. Advantages of this approach include:

• Maintaining Git's security check mechanism
• Controlling access through the principle of least privilege
• Facilitating auditing and permission management

When implementing the sudo solution, consider creating a dedicated system user for Git operations rather than directly using developer accounts. This better isolates permissions and reduces security risks.

For continuous integration/continuous deployment (CI/CD) environments, the case study in the reference article provides valuable insights. Similar issues encountered during Unity builds indicate that this problem is particularly common in automated build environments. Solutions typically involve adding appropriate Git configuration commands to build scripts or adjusting user permission settings in the build environment.

Security Considerations and Risk Assessment

Regardless of the chosen solution, security implications must be thoroughly considered:

When using the safe.directory configuration, assess the trustworthiness of directory contents. If directories may contain user-uploaded content or files from untrusted sources, disabling security checks could introduce risks. In such cases, consider combining other security measures, such as file integrity checks and access log monitoring.

While sudo configurations are relatively secure, they require careful management. Over-authorization may lead to privilege escalation vulnerabilities. Recommendations include:

1. Authorizing only necessary Git commands
2. Avoiding the ALL keyword and specifying exact command paths
3. Regularly auditing sudo configurations to remove unnecessary permissions

Executing Git commands in web server environments inherently carries some risk. Consider alternatives such as using programming interfaces of Git libraries instead of command-line calls, or moving Git operations to dedicated build servers.

Conclusion

While the security update introduced in Git 2.35.2 has caused compatibility issues, it represents a necessary security improvement. Resolving the "unsafe repository" error requires balancing security needs with functional requirements. Through proper configuration of safe.directory, well-designed sudo permission management, or appropriate system architecture adjustments, normal workflows can be maintained while ensuring security.

For most production environments, we recommend the sudo solution combined with the principle of least privilege. This approach maintains Git's security mechanism while providing necessary flexibility. Additionally, development teams should:

• Promptly update Git to the latest secure version
• Conduct regular security audits
• Establish standardized deployment and permission management processes

By addressing this issue systematically, not only can the current error be fixed, but overall system security and maintainability can be enhanced.