The NFS server is also running Centos 7.2 and an IPA client.
When Apache starts returning "no permission" error, gssproxy would log the
messages that I posted earlier (for service "nfs-client"). Also I don't see
any krb5cc file created in /var/lib/gssproxy/clients/. Whereas if I remove
/var/lib/gssproxy/clients/krb5cc_apache, restart gssproxy, and hit the URL that maps to an
user's home directory, I would see the file /var/lib/gssproxy/clients/krb5cc_apache
get created, as expected according to the gssproxy.conf.
Here is /etc/gssproxy/gssproxy.conf:
[gssproxy]
debug = yes
[service/apache]
mechs = krb5
cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_apache
cred_store = client_keytab:/var/lib/gssproxy/clients/http.keytab
cred_usage = initiate
euid = 48
[service/nfs-server]
mechs = krb5
socket = /run/gssproxy.sock
cred_store = keytab:/etc/krb5.keytab
trusted = yes
kernel_nfsd = yes
euid = 0
[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
On Thursday, February 25, 2016 1:38 PM, Simo Sorce <simo(a)redhat.com> wrote:
On Thu, 2016-02-25 at 15:59 +0000, Wen Liang wrote:
My CentOS 7.2 server:
* Enrolled IPA client
* Automount configured with NFSv4 krb5 mount for user home directories.
Everything works. IPA users can login and their home directory would automatically be
mounted.
Now, I am trying to configure the server's Apache to expose certain users' home
directory for web. To do this, I followed
https://fedorahosted.org/gss-proxy/wiki/NFS to configure gssproxy (no impersonation).
And this works... for awhile. After idling awhile, Apache would report no permission,
and gssproxy debug message would show:
gssproxy: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service
"nfs-client", euid: 0, socket: (null)
gssproxy: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service
"nfs-client", euid: 0, socket: (null)
What I don't understand is why is it using service "nfs-client"?
Shouldn't it be using service "apache", which is set above the section for
"nfs-client" in gssproxy.conf? I say this because if I restart gssproxy, Apache
would work again, and the debug message would show (as expected):
gssproxy: Client connected (fd = 12) (pid = 3158) (uid = 48) (gid = 48) (context =
system_u:system_r:gssd_t:s0)
gssproxy: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "apache",
euid: 48, socket: (null)
gssproxy: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service
"apache", euid: 48, socket: (null)
gssproxy: gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for service
"apache", euid: 48, socket: (null)
But after idling awhile, Apache would again stop working and gssproxy debug messages
would show it's using "nfs-client" again.
So why is it not using service "apache" all the time and instead falls back to
"nfs-client"?
The nfs-client (rpc.gssd I assume here) acquires credentials with the
nfs (or host) keytab to connect to the remote server for non-user
related operations.
I think it is unrelated to your problem with apache, do you see any
error returned by gssproxy when apache stops getting access ?
What is the nfs server ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York