Diagnosing Squid Denials Under SELinux
Distinguish Squid access rules, filesystem permissions, port labels, and host security-policy denials before changing enforcement.
A Squid-generated HTTP access denial and an operating-system “Permission denied” occur at different boundaries. Identify whether Squid was opening a file, binding a socket, connecting outward, or rejecting a client request.
Correlate the audit event
On SELinux systems, match the service error to its audit record. The source domain, target type, object class, and denied permission show which operation policy blocked. Correct Unix ownership does not establish that the security label is appropriate.
A custom listener port can require the corresponding port label. A relocated log or cache directory can require file labeling. For a Squid log-path failure, also check directory traversal and writer permissions before attributing it to a label. Permission for an unusual outbound service is another operation again; Red Hat's Squid SELinux examples distinguish these cases.
Use the installed distribution's policy and administration guidance. Package paths, labels, and confinement can differ across images. On systems using AppArmor, inspect its profile instead of applying SELinux commands.
Correct the policy or location implicated by the evidence while retaining host enforcement. Squid's own client authentication and access rules still apply after the host-policy problem is repaired.