In FreeIPA 4.9.0rc2 on Rawhide, a use of unique credential caches fails as mod_auth_gssapi runs under apache user and /run/ipa/ccaches directory is owned by ipaapi group and user. As a result, even deployment of ipa-server-install fails:
mod_auth_gssapi
apache
/run/ipa/ccaches
ipaapi
ipa-server-install
.... Restarting the KDC dnssec-validation no Configuring DNS (named) [1/11]: generating rndc key file [2/11]: adding DNS container [3/11]: setting up our zone [4/11]: setting up our own record [5/11]: setting up records for other masters [6/11]: adding NS record to the zones [7/11]: setting up kerberos principal [8/11]: setting up named.conf created new /etc/named.conf created named user config '/etc/named/ipa-ext.conf' created named user config '/etc/named/ipa-options-ext.conf' [9/11]: setting up server configuration [10/11]: configuring named to start on boot [11/11]: changing resolv.conf to point to ourselves Done configuring DNS (named). Restarting the web server to pick up resolv.conf changes Configuring DNS key synchronization service (ipa-dnskeysyncd) [1/7]: checking status [2/7]: setting up bind-dyndb-ldap working directory [3/7]: setting up kerberos principal [4/7]: setting up SoftHSM [5/7]: adding DNSSEC containers [6/7]: creating replica keys [7/7]: configuring ipa-dnskeysyncd to start on boot Done configuring DNS key synchronization service (ipa-dnskeysyncd). Restarting ipa-dnskeysyncd Restarting named Updating DNS system records Configuring client side components This program will set up FreeIPA client. Version 4.9.0rc2 Using existing certificate '/etc/ipa/ca.crt'. Client hostname: m2.ipa2.test Realm: IPA2.TEST DNS Domain: ipa2.test IPA Server: m2.ipa2.test BaseDN: dc=ipa2,dc=test Configured sudoers in /etc/authselect/user-nsswitch.conf Configured /etc/sssd/sssd.conf cannot connect to 'https://m2.ipa2.test/ipa/json': Unauthorized The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information Configuration of client side components failed! The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
If I'd check the errors_log, the reason is there:
errors_log
[Wed Dec 09 10:14:03.352002 2020] [auth_gssapi:error] [pid 5751:tid 5921] [client 192.168.122.212:34756] creating unique ccache file /run/ipa/ccaches/host~m2.ipa2.test@IPA2.TEST-FRTWr5 failed, referer: https://m2.ipa2.test/ipa/xml
[root@m2 ~]# ps axu|grep 5751 apache 5751 0.0 0.7 2349612 20664 ? Sl 10:13 0:00 /usr/sbin/httpd -DFOREGROUND root 6162 0.0 0.0 6256 920 pts/0 S+ 10:20 0:00 grep --color=auto 5751 [root@m2 ~]# ls -la /run/ipa/ccaches/ total 0 drwxrwx---. 2 ipaapi ipaapi 40 Dec 9 10:13 . drwx--x--x. 3 root root 100 Dec 9 10:13 ..
This issue seems to have the same cause as with infamous failed to set perms (3140) on file (/run/ipa/ccaches/user@REALM)!, -- the chown is being done by httpd process running as apache instead of ipaapi, only that in the case of unique ccaches we cannot even create them.
failed to set perms (3140) on file (/run/ipa/ccaches/user@REALM)!,
httpd
Since /run/ipa/ccaches is on tmpfs, I think we can fix this by adding an ACL to the tmpfiles' definition for IPA.
I tried
[root@m2 ~]# cat /usr/lib/tmpfiles.d/ipa.conf d /run/ipa 0711 root root d /run/ipa/ccaches 2770 ipaapi ipaapi a+ /run/ipa/ccaches - - - - g:apache:rwx
And this configuration allows to create credentials caches and also automatically (due to SGID bit) set them to ipaapi group.
You could also change the group of /run/ipa/ccaches to apache. The ipaapi user is member of both ipaapi and apachegroup.
Do we then need to change
GssapiDelegCcachePerms mode:0660 gid:ipaapi
to set to 'apache' as well? Because otherwise mod_auth_gssapi will be complaining.
Does mod_auth_gssapi open files in the parent process? If it just has to create and remove files, then write permission on the directory should be enough. The parent process may not be able to chgrp files to ipaapi group, though.
It is not able to do chgrp indeed. I checked error logs and every time there is a complaint from mod_auth_gssapi about inability to change permissions -- in this case or in the older ones -- it is always done from the process that is running under apache user, not ipaapi.
Tried to change the group to apache and add SGID/SUID to the directory, got another problem: all ccache files now have 0600 permissions and ipaapi:apache ownership. This means we cannot actually read them and always end up using HTTP/... principal in all requests:
ipaapi:apache
HTTP/...
[root@m2 ~]# ls -laZ /run/ipa/ccaches/ total 20 drwsrws---. 2 ipaapi apache system_u:object_r:var_run_t:s0 140 Dec 9 12:59 . drwx--x--x. 3 root root system_u:object_r:var_run_t:s0 100 Dec 9 12:57 .. -rw-------. 1 ipaapi apache system_u:object_r:httpd_var_run_t:s0 2810 Dec 9 12:59 admin@IPA2.TEST-Haal4F -rw-------. 1 ipaapi apache system_u:object_r:httpd_var_run_t:s0 2810 Dec 9 12:57 host~m2.ipa2.test@IPA2.TEST-0atj5a -rw-------. 1 ipaapi apache system_u:object_r:httpd_var_run_t:s0 2810 Dec 9 12:57 host~m2.ipa2.test@IPA2.TEST-17jsPa -rw-------. 1 ipaapi apache system_u:object_r:httpd_var_run_t:s0 2810 Dec 9 12:57 host~m2.ipa2.test@IPA2.TEST-1KrsTe -rw-------. 1 ipaapi apache system_u:object_r:httpd_var_run_t:s0 2810 Dec 9 12:57 host~m2.ipa2.test@IPA2.TEST-Nfr6Dd [root@m2 ~]# kinit admin Password for admin@IPA2.TEST: [root@m2 ~]# ipa ping ---------------------------------------------- IPA server version 4.9.0rc2. API version 2.240 ---------------------------------------------- [root@m2 ~]# tail -1 /var/log/httpd/error_log [Wed Dec 09 12:59:03.969916 2020] [wsgi:error] [pid 26799:tid 27111] [remote 192.168.122.212:36732] ipa: INFO: [jsonserver_kerb] HTTP/m2.ipa2.test@IPA2.TEST: ping/1(version='2.240'): SUCCESS
With the following permissions and removing chgrp part from mod_auth_gssapi setup, it now works:
[root@m2 ~]# cat /usr/lib/tmpfiles.d/ipa.conf d /run/ipa 0711 root root d /run/ipa/ccaches 6770 ipaapi ipaapi a+ /run/ipa/ccaches - - - - g:apache:rwx
PR: https://github.com/freeipa/freeipa/pull/5328
master:
ipa-4-9:
Metadata Update from @abbra: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.