This error occurs when SELinux (Security-Enhanced Linux) blocks Git from executing the git-remote-https helper binary. SELinux enforces mandatory access control policies that prevent unauthorized execution of binaries, even when standard Unix permissions would allow it. The fix involves adjusting SELinux contexts or policies.
SELinux is a Linux kernel security module that enforces mandatory access control (MAC) policies beyond traditional Unix discretionary access control (file permissions). When Git tries to communicate with a remote repository over HTTPS, it spawns the `git-remote-https` helper binary. SELinux is blocking this execution because the security context of the binary, the calling process, or the target location doesn't match the configured policy. This error is distinct from regular "Permission denied" errors because: 1. **Standard file permissions may be correct** - you can `ls -l` the binary and see it's executable 2. **Running as root doesn't help** - SELinux policies apply even to the root user 3. **The error specifically mentions SELinux** - the kernel is explicitly telling you SELinux is the blocker Common scenarios where this occurs: - Git was installed in a non-standard location (e.g., compiled from source) - The binary was copied or moved, losing its SELinux context - A custom SELinux policy is too restrictive - The system was restored from backup without preserving SELinux labels - You're running Git in a container or chroot with different SELinux contexts
First, confirm SELinux is in enforcing mode and is the actual cause:
# Check SELinux status
getenforce
sestatusIf it shows Enforcing, SELinux is active. Check the audit log for denials:
# View recent SELinux denials (requires root)
sudo ausearch -m avc -ts recent
# Or check the audit log directly
sudo grep "denied.*git" /var/log/audit/audit.log | tail -20You should see entries like:
type=AVC msg=audit(...): avc: denied { execute } for pid=12345 comm="git" name="git-remote-https" ...To confirm SELinux is the problem, temporarily set it to permissive mode:
# Set SELinux to permissive (allows but logs violations)
sudo setenforce 0
# Try your git command again
git clone https://github.com/example/repo.git
# Re-enable enforcing mode
sudo setenforce 1Warning: Running in permissive mode reduces system security. Only use this for testing, then fix the underlying issue.
If git works in permissive mode, SELinux policies are definitely the cause.
The most common fix is to restore the correct SELinux labels on Git binaries:
# Restore default SELinux contexts for git-core directory
sudo restorecon -Rv /usr/libexec/git-core/
# Also restore the main git binary
sudo restorecon -v /usr/bin/gitThe restorecon command resets files to their default SELinux context as defined in the policy.
If git was installed elsewhere:
# For /usr/local installation
sudo restorecon -Rv /usr/local/libexec/git-core/
sudo restorecon -v /usr/local/bin/gitExamine the current SELinux context of the problematic binary:
# View SELinux context of git binaries
ls -Z /usr/libexec/git-core/git-remote-https
ls -Z /usr/bin/gitExpected output should show a context like system_u:object_r:bin_t:s0 or system_u:object_r:git_exec_t:s0.
If the context is wrong (e.g., unconfined_u:object_r:user_home_t:s0), fix it:
# Set the correct type for executable binaries
sudo chcon -t bin_t /usr/libexec/git-core/git-remote-https
# Or recursively for all git-core binaries
sudo chcon -R -t bin_t /usr/libexec/git-core/Note: chcon changes are temporary and may be reset by restorecon. For permanent changes, use semanage fcontext.
For custom Git installations, add a permanent SELinux file context rule:
# Add a file context rule for git binaries
sudo semanage fcontext -a -t bin_t "/opt/git/libexec/git-core(/.*)?"
# Apply the new context
sudo restorecon -Rv /opt/git/libexec/git-core/Verify the rule was added:
# List custom file context rules
sudo semanage fcontext -l -CThis ensures the context survives system updates and restorecon operations.
Sometimes the issue is the SELinux context of the repository location:
# Check context of your repository directory
ls -Zd ~/projects/myrepo
# If home directory has wrong context, restore it
restorecon -Rv ~/
# For specific repository
restorecon -Rv ~/projects/myrepoIf the repository is on a non-standard mount (like NFS or a second disk), you may need to mount it with the correct context:
# Example fstab entry with SELinux context
/dev/sdb1 /data ext4 defaults,context=system_u:object_r:user_home_t:s0 0 2If standard context fixes don't work, create a custom policy module:
# Generate a policy module from audit denials
sudo ausearch -m avc -ts recent | audit2allow -M mygit
# Review what the policy allows
cat mygit.te
# Install the policy module
sudo semodule -i mygit.ppImportant: Review the generated policy before installing. Only allow specific necessary permissions.
To remove a custom module later:
sudo semodule -r mygit### Understanding SELinux Contexts
SELinux labels have four parts: user:role:type:level
For Git binaries, you typically want:
- Type: bin_t (standard executable) or git_exec_t (Git-specific on some systems)
- Role: object_r (for files)
- User: system_u (system service) or unconfined_u (user-installed)
### Debugging SELinux Issues
Use these tools to diagnose SELinux problems:
# Real-time monitoring of SELinux denials
sudo tail -f /var/log/audit/audit.log | grep -i denied
# Detailed denial analysis
sudo sealert -a /var/log/audit/audit.log
# Check what SELinux booleans affect git
getsebool -a | grep git### Container Environments
When running Git in containers on SELinux-enforcing hosts:
1. Podman/Docker: Add :Z or :z suffix to volume mounts:
podman run -v /home/user/repo:/repo:Z myimage2. Use `--security-opt`:
docker run --security-opt label=disable myimage3. For Kubernetes: Set SELinux options in the security context:
securityContext:
seLinuxOptions:
type: spc_t### RHEL/CentOS/Fedora Specifics
On Red Hat-based systems, Git packages are labeled correctly by default. If labels are missing:
# Reinstall git package to restore labels
sudo dnf reinstall git-core
# Or just fix labels
sudo fixfiles restore /usr/libexec/git-core### When to Disable SELinux
Never permanently disable SELinux in production. If you must run in permissive mode temporarily:
# Make permissive mode survive reboot (not recommended)
sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/configInstead, fix the policy or use audit2allow to create targeted exceptions.
### Checking for Conflicting Modules
List installed SELinux modules that might affect Git:
sudo semodule -l | grep -i gitIf you find conflicting custom modules, consider removing them:
sudo semodule -r conflicting_module_namekex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server
fatal: unable to access: Proxy auto-configuration failed
How to fix 'Proxy auto-configuration failed' in Git
fatal: unable to access: Authentication failed (proxy requires basic auth)
How to fix 'Authentication failed (proxy requires basic auth)' in Git
fatal: unable to access: no_proxy configuration not working
How to fix 'no_proxy configuration not working' in Git
fatal: unable to read tree object in treeless clone
How to fix 'unable to read tree object in treeless clone' in Git