Quando o Apache httpd tenta acessar um diretório de usuários montado automaticamente com sec=krb5p e, presumivelmente, outras opções sec=krb , gssproxy emite uma mensagem de falha e o servidor da Web responde com 403 Forbidden . A opção de depuração no gssproxy não foi suficientemente esclarecedora.
Para excluir nenhum problema de RPCGSS , o 403 não será emitido quando um KRB5CC válido de uidNumber 48 (apache) estiver presente em / tmp e o servidor da Web exibirá a página apropriada. No entanto, isso é devido ao comportamento de rpc.gssd . gssproxy ainda emite a mesma mensagem de falha.
gssproxy: gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service "nfs-client", euid: 0, socket: (null)
gssproxy: gssproxy[639]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
# cat /etc/gssproxy/gssproxy.conf
[gssproxy]
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
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
# klist -ke /var/lib/gssproxy/clients/$(id -u apache).keytab
Keytab name: FILE:/var/lib/gssproxy/clients/48.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 apache/[email protected] (aes256-cts-hmac-sha1-96)
2 apache/[email protected] (aes128-cts-hmac-sha1-96)
2 apache/[email protected] (camellia256-cts-cmac)
2 apache/[email protected] (camellia128-cts-cmac)
# cat /etc/systemd/system/gssproxy.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/gssproxy -D --debug
Eu usei strace para ver que o gssproxy estava procurando pelo keytab em /var/kerberos/krb5/user/48/client.keytab. Eu também precisava definir o contexto do selinux:
chcon -t krb5_keytab_t /var/kerberos/krb5/user/48/client.keytab
ls -lZ /var/kerberos/krb5/user/48/client.keytab
-r--------. apache apache unconfined_u:object_r:krb5_keytab_t:s0 /var/kerberos/krb5/user/48/client.keytab
Parece que a sub-rotina HTTP está tomando precedência sobre a sub-rotina nfs-client para o UID 48.