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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc