Repeated mod_auth_gssapi chmod warnings on private IPAAPI-owned delegated caches

[juniper275]

Environment

• Rocky Linux 10.2, FreeIPA 4.13.4-1.el10_2.
• mod_auth_gssapi 1.6.5-8.el10, gssproxy 0.9.2-10.el10.
• RPM verification of these three packages succeeds without differences.
• Standard IPA configuration: GssapiDelegCcachePerms mode:0660.
• Cache directory 06770 ipaapi:ipaapi, with an effective apache group rwx ACL.
• Apache workers have no effective capabilities and belong to the ipaapi group.

Observed behavior

During successful Web UI/API use, Apache logs repeatedly:

failed to set perms (3140) on file (/run/ipa/ccaches/[redacted-cache-name])!

For all 436 observed warnings, the PID still maps to an apache worker and the
referenced existing cache is owned by ipaapi:ipaapi with mode 0600. Application
requests can still return SUCCESS. No credential-cache content was read.

In mod_auth_gssapi src/environ.c, mag_set_ccname_envvar compares the current
protection with the configured protection and calls apr_file_perms_set even
when the worker does not own the cache. The warning prints the requested APR
mask, not the returned error status.

Isolated reproduction

On the same system, use empty temporary files outside the live cache directory:

1. Create an empty ipaapi:ipaapi file, mode 0600, in a traversable test directory.
2. As apache with its normal groups, call the installed libapr-1
   apr_file_perms_set(path, 0x0660).
3. Result: status 1 / EPERM; the file remains 0600.
4. Repeat as ipaapi: success; resulting Unix mode 0660.

The alternative path matters: an apache:ipaapi file at 0600 is unreadable to
ipaapi, while the same file at 0660 is readable. Therefore globally changing
GssapiDelegCcachePerms to 0600 is not established as a safe general workaround.

All temporary fixtures were removed and production configuration hashes were
unchanged. No ptrace on production workers, no personal credentials involved.

Requested clarification/fix

Please clarify the supported ownership/permissions behavior for IPAAPI-created
versus Apache-created delegated caches. Can the existing-private-cache path
avoid the unnecessary permission change and warning without regressing the
Apache-created cache path or obscuring genuine permission failures?

Any proposed change should be tested with password login, SPNEGO/Kerberos,
session reuse, logout, and expiry. No custom module or workaround is deployed.

Primary references

• https://github.com/gssapi/mod_auth_gssapi/blob/v1.6.5/src/environ.c#L398
• https://github.com/freeipa/freeipa/blob/master/install/share/ipa.conf.template
• https://github.com/freeipa/freeipa/blob/master/init/tmpfilesd/ipa.conf.in
• https://pagure.io/freeipa/c/7d1a6886538360fb340eb4423660d11ee4af7e39

[simo5]

If GssapiDelegCcachePerms does not work as desired it can be unset.

Ccache files in the directory can also be managed via default ACLs on the directory to provide access to the required parties.

From the POV of mod_auth_gssapi this is not a bug but merely a configuration choice

[juniper275]

Thanks for the clarification.

Could you provide a concrete ACL/default ACL configuration for safely removing GssapiDelegCcachePerms mode:0660 in FreeIPA, ideally with the exact setfacl commands, expected getfacl output, and expected ownership/permissions of newly created caches?

The current FreeIPA upstream tmpfiles configuration is:

d /run/ipa 0711 root root
d /run/ipa/ccaches 6770 ipaapi ipaapi
a+ /run/ipa/ccaches - - - - g:apache:rwx

We understand that this grants directory access and is different from default ACLs inherited by new files. Could your example cover both creation paths?

• Caches created by Apache must remain accessible to the ipaapi backend.
• Caches created by ipaapi are currently private (0600), and Apache encounters the reported chmod warning when reusing them.

In particular, how should the inherited ACL entries and ACL mask behave when a cache is created with mode 0600?

FreeIPA commit 7d1a688 explicitly retains this directive because removing it caused authentication redirects to fail. How does the proposed ACL configuration replace that requirement, and are any accompanying Apache/GSSAPI changes needed?

The goal is to avoid these warnings while preserving password login, SPNEGO/Kerberos authentication, and session reuse/logout/expiry. Thanks for helping clarify a safe configuration for this integration.