Comment inline. On Tue, 2018-02-13 at 16:58 +0100, Ray via FreeIPA-users wrote: > Hi Simo, > > > > Hi there, > > > > > > I'm trying to make Apache to access a kerberized document root on > > > CentOS > > > 7 using gssproxy. So far without success. On the web server machine > > > (=NFS client) I configured a gss-proxy config file: > > > > > > # cat /etc/gssproxy/99-nfs-client.conf > > > [service/nfs-client] > > > mechs = krb5 > > > cred_store = keytab:/etc/krb5.keytab > > > cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U > > > cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab > > > cred_usage = initiate > > > allow_any_uid = yes > > > trusted = yes > > > euid = 0 > > > > > > In addition to this I set up a credentials cache > > > /var/lib/gssproxy/clients/krb5cc_<httpd uid> > > > > What did you put in this file? > > Probably I made a mistake here: I got the keytab from the IPA server and > named it /var/lib/gssproxy/clients/krb5cc_<httpd uid> instead of > /var/lib/gssproxy/clients/<httpd_uid>.keytab. I fixed that now (by > mv'ing it) and ran > > systemctl stop gssproxy to not have gssproxy as a daemon > gssproxy -d -i -C /etc/gssproxy/ & to have gssproxy dump any debug > msgs to my terminal
Note that running gssproxy from a root shell makes it run in unconfined mode, so later on the files it create may have SELinux contexts that are wrong and gssproxy may fail in various ways. > After temporarily mounting the docroot to /mnt using > > mount -vv -t nfs4 nfsserver:/path/to/export /mnt > > I saw some debug messages flying by: > > mount.nfs4: timeout set for Tue Feb 13 08:20:21 2018 > mount.nfs4: trying text-based options > 'vers=4.1,addr=<nfsservip>,clientaddr=<nfsclientip>' > [2018/02/13 08:18:21]: Client connected (fd = 9)[2018/02/13 08:18:21]: > (pid = 623) (uid = 0) (gid = 0)[2018/02/13 08:18:21]: (context = > system_u:system_r:gssd_t:s0)[2018/02/13 08:18:21]: > [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) > for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) > for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) > for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) > for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > [2018/02/13 08:18:21]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: 0,socket: (null) > > And when I then su to the apache user and try to access the directory, I > see some more debug messages: > > # su -s /bin/bash <apache-user> > bash-4.2$ cd /mnt > [2018/02/13 08:19:33]: Client connected (fd = 9)[2018/02/13 08:19:33]: > (pid = 623) (uid = <httpd uid>) (gid = <httpd uid>)[2018/02/13 > 08:19:33]: (context = system_u:system_r:gssd_t:s0)[2018/02/13 > 08:19:33]: > [2018/02/13 08:19:33]: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) > for service "nfs-client", euid: <httpd uid>,socket: (null) > [2018/02/13 08:19:33]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: <httpd > uid>,socket: (null) > [2018/02/13 08:19:34]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: <httpd > uid>,socket: (null) > bash: cd: /mnt: Permission denied > > Unfortunately still no success, as the last line indicates, however I > get to see a new /var/lib/gssproxy/clients/krb5cc_<httpd uid> file tat > was created by gssproxy, I presume: > > -rw-------. 1 root root 1819 Feb 13 08:19 krb5cc_<httpd uid> > > The keytab file /var/lib/gssproxy/clients/<httpd uid>.keytab looks like > this: > > # klist -ke <httpd uid>.keytab > Keytab name: FILE:<httpd uid>.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 1 nfs/<nfsserver-fqdn@REALM> (aes256-cts-hmac-sha1-96) > 1 nfs/<nfsserver-fqdn@REALM> (aes128-cts-hmac-sha1-96) > 1 host/<nfsclient-fqdn@REALM> (aes256-cts-hmac-sha1-96) > 1 host/<nfsclient-fqdn@REALM> (aes128-cts-hmac-sha1-96) This is not the keytab you want most probably. You want a keytab with credentials that the server can map to a UID/GID, usually that is done for user principals. However the server can be configured to map a specific service principal name to a local use as well, it's on the server side at this point. > > > The configuration is correct, although you could tailor it specifically > > to the apache process (setting a strinct euid not using allow_any_uid > > nor trusted). > > Ok, that would make sense. Will do that once I can access the docroot as > apache user. > > Do the debug messages shown above indicate what might be wrong? The > "socket: (null)" bit perhaps? > > The last two log lines looked rather promising to me: > [2018/02/13 08:19:33]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: <httpd > uid>,socket: (null) > [2018/02/13 08:19:34]: gp_rpc_execute: executing 8 > (GSSX_INIT_SEC_CONTEXT) for service "nfs-client", euid: <httpd > uid>,socket: (null) The (null) represents the default socket, not a bug. Unfortunately the default log level does not show the result of the calls, but it is normal to see 2 init context calls, so it seem to be working right on the gssproxy side. > This is probably the confirmation about the credtials being written to > krb5cc_<httpd uid>, right? Still getting "permission denied" would > perhaps indicate that the apache user has no access to the NFS mount, > even considering the credential store? The fact rpc-gssd contacted gssproxy to get creedntials, means that on the server running apache you've got access to /mnt, as you were able to walk in and cause authentication to happen. I would look at the server side at this stage (see above). HTH, Simo. > Best, > Ray > > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
