Yes, restarting rpc.gssd (systemctl restart rpcgssd) also solves the Apache permission.
On Thursday, February 25, 2016 3:38 PM, Simo Sorce <simo(a)redhat.com> wrote:
On Thu, 2016-02-25 at 20:21 +0000, Wen Liang wrote:
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.
This sounds odd, if you see only euid=0 connecting then it means
rpc.gssd is not accessing gssproxy with the right credentials.
Does the problem also go away if you restart rpc.gssd
(nfs-secure-client) instead of restarting gssproxy ?
Simo.
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