How to fix error: cannot exec '/usr/libexec/git-core/git-remote-https': Permission denied (SELinux) in Git

GitINTERMEDIATEMEDIUMUpdated Dec 2, 2025· 130 views

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.

Quick fix

Fixes EACCES

# Check SELinux status
getenforce
sestatus
  1. Verify SELinux is causing the issue
  2. Temporarily test with SELinux permissive mode
  3. Restore SELinux context on Git binaries
  4. Check and fix SELinux context manually
git — error
# Check SELinux status
getenforce
sestatus
error: cannot exec '/usr/libexec/git-core/git-remote-https': Permission denied (SELinux)

What this error means

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

Typical symptoms

  • Git clone, fetch, or push to HTTPS URLs fails with Permission denied (SELinux)
  • Git operations work with SSH but fail with HTTPS
  • The error references /usr/libexec/git-core/ specifically
  • Running git with sudo still produces the same error
  • Standard file permissions look correct (ls -l shows executable)
  • The error appeared after system update, migration, or restore from backup
  • Git works in some directories but not others
  • Other users on the same system have the same issue

Common causes

  1. SELinux context labels are missing or incorrect on Git binaries (most common)
  2. Git was installed from source without proper SELinux labels
  3. Git binaries were copied or moved, stripping their SELinux context
  4. System restored from backup without SELinux extended attributes
  5. Running in a container with restrictive SELinux policy
  6. SELinux policy update introduced stricter rules
  7. Home directory or repository path has wrong SELinux context
  8. Custom SELinux module is blocking git execution

How to fix "error: cannot exec '/usr/libexec/git-core/git-remote-https': Permission denied (SELinux)"

1Verify SELinux is causing the issue

First, confirm SELinux is in enforcing mode and is the actual cause:

bash
# Check SELinux status
getenforce
sestatus

If it shows Enforcing, SELinux is active. Check the audit log for denials:

bash
# 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 -20

You should see entries like:

bash
type=AVC msg=audit(...): avc:  denied  { execute } for  pid=12345 comm="git" name="git-remote-https" ...
2Temporarily test with SELinux permissive mode

To confirm SELinux is the problem, temporarily set it to permissive mode:

bash
# 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 1

Warning: 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.

3Restore SELinux context on Git binaries

The most common fix is to restore the correct SELinux labels on Git binaries:

bash
# 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/git

The restorecon command resets files to their default SELinux context as defined in the policy.

If git was installed elsewhere:

bash
# For /usr/local installation
sudo restorecon -Rv /usr/local/libexec/git-core/
sudo restorecon -v /usr/local/bin/git
4Check and fix SELinux context manually

Examine the current SELinux context of the problematic binary:

bash
# View SELinux context of git binaries
ls -Z /usr/libexec/git-core/git-remote-https
ls -Z /usr/bin/git

Expected 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:

bash
# 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.

5Make SELinux context changes permanent

For custom Git installations, add a permanent SELinux file context rule:

bash
# 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:

bash
# List custom file context rules
sudo semanage fcontext -l -C

This ensures the context survives system updates and restorecon operations.

6Fix SELinux context on home directory or repository

Sometimes the issue is the SELinux context of the repository location:

bash
# 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/myrepo

If the repository is on a non-standard mount (like NFS or a second disk), you may need to mount it with the correct context:

bash
# Example fstab entry with SELinux context
/dev/sdb1 /data ext4 defaults,context=system_u:object_r:user_home_t:s0 0 2
7Create a custom SELinux policy module (advanced)

If standard context fixes don't work, create a custom policy module:

bash
# 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.pp

Important: Review the generated policy before installing. Only allow specific necessary permissions.

To remove a custom module later:

bash
sudo semodule -r mygit

Advanced notes

### 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:

bash
# 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:

bash
podman run -v /home/user/repo:/repo:Z myimage

2. Use `--security-opt`:

bash
docker run --security-opt label=disable myimage

3. For Kubernetes: Set SELinux options in the security context:

yaml
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:

bash
# 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:

bash
# Make permissive mode survive reboot (not recommended)
sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config

Instead, fix the policy or use audit2allow to create targeted exceptions.

### Checking for Conflicting Modules

List installed SELinux modules that might affect Git:

bash
sudo semodule -l | grep -i git

If you find conflicting custom modules, consider removing them:

bash
sudo semodule -r conflicting_module_name

Frequently asked questions

What does "EACCES" mean?
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.
How do I fix "EACCES"?
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.
What causes "EACCES"?
SELinux context labels are missing or incorrect on Git binaries (most common) Git was installed from source without proper SELinux labels Git binaries were copied or moved, stripping their SELinux context
Is the "EACCES" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading