On 3/3/2021 12:20 PM, Simo Sorce wrote:
On Wed, 2021-03-03 at 11:26 -0500, Jason Keltz wrote:
> On 3/3/2021 10:38 AM, Simo Sorce wrote:
>> On Tue, 2021-03-02 at 16:57 -0500, Jason Keltz wrote:
>>> On 3/2/2021 4:48 PM, Simo Sorce wrote:
>>>> On Tue, 2021-03-02 at 15:46 -0500, Jason Keltz wrote:
>>>>> Hi.
>>>>>
>>>>> I'm running gssproxy on many hosts with CentOS 7.9. gssproxy is
>>>>> constantly generating this error in syslog for every host,
repeatedly:
>>>>>
>>>>> Mar 02 15:41:53 sel01 gssproxy[977]: (OID: { 1 2 840 113554 1 2 2 })
>>>>> Unspecified GSS failure. Minor code may provide more information,
No
>>>>> creden...che found
>>>>> Mar 02 15:41:53 sel01 gssproxy[881]: gssproxy[977]: (OID: { 1 2 840
>>>>> 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide
more
>>>>> informa...che found
>>>>> M
>>>>>
>>>>> Looking in more detail, it's constantly trying to open
>>>>> /var/lib/gssproxy/clients/krb5cc_42. UID 42 is gdm. It's a
local user
>>>>> not in Kerberos. When I strace the gdm process, I don't see it
>>>>> constantly trying to access any particular share that would required
>>>>> Kerberos. I want gssproxy to completely ignore gdm altogether. How
>>>>> would I go about doing this?
>>>> So normally the GSS-Proxy mechglue is not invoked at all, as it is
>>>> dependent on having an envronment variable set up.
>>>> Did you set the env var to enable gssproxy system wide ?
>>>> It is normally preferred to prepend it only for applications that you
>>>> want to intercept by modifying unit files individually.
>>> Hi Simo,
>>>
>>> All the clients are running gssproxy by default. As far as I know, I
>>> haven't changed anything at all except adding to 99-nfs-client.conf
>>> krb5_principal.
>>>
>>> I assumed this was the default behaviour. /etc/gssproxy/gssproxy.conf
>>> contains nothing but "[gssproxy]".
>>>
>>> Where would I look?
>> Ah NFS, well what is seem to be happening is that GDM is trying to
>> access some NFS mounts, and causing the NFS client to try to
>> authenticate on behalf of the gdm user.
>>
>> I assume gdm is trying to check some user home directory you mount over
>> NFS?
>>
>> If that's the case (and you want to grant gdm the ability to perform
>> those accesses) you could define an additional configuration section
>> for NFS in gssproxy.conf with euid=42
>>
>> As that is a more specific configuration it should match first, you can
>> then configure it to let gdm use the host keytab for authentication
>> (using the machine krb5 principal), this will generally end up granting
>> "nobody" user access on the NFS server, or similar (depending on your
>> id mapping configuration there.
> Hi Simo,
>
> I assume, as you said, that gdm is trying to access the NFS home
> directories, but why would it be doing that? GDM home directory is not
> on an NFS share. Before a user logs in, it's not clear what it would be
> doing over and over again. Any idea how I could track it (and stop it)?
>
> Before login, GDM, I assume should only read the Init startup. Init does
> indeed refer to some NFS mounts. However, Init runs as root, and root
> is mapped to the machine account. I've verified that those accesses are
> by root, and they work exactly as expected getting the proper access.
>
> Rather than giving gdm user access to the share, can I tell gssproxy to
> ignore requests from this user instead? I'd like to know what it's
> doing and why. I'm just not sure how to find it.
We do not have a way in gssproxy to drop requests on the floor at this
time, unfortunately.
I figured out that /etc/fonts/local.conf included a font from the NFS
share which was causing gdm to constantly try the share, and gssproxy to
constantly bang on syslog. I resolved that, and the constant errors
generated from gdm went away. When I reboot the machine, I see no
gssproxy errors. However, when any user logs in, I see a few
"Unspecified GSS failure" errors, but my home directory is mounted, and
everything is fine. Why would I get these errors?
Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]:
[status] Handling query input: 0x56413aeb64f0 (116)
Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]:
[status] Processing request [0x56413aeb64f0 (116)]
Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]:
[status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0 (116)]
Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]:
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service
"nfs-client", euid: 1004,socket: (null)
Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_ARG_ACQUIRE_CRED( call_ctx: {
"" [ ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null>
time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } }
cred_usage: INITIATE initiator_time_r\
eq: 0 acceptor_time_req: 0 )
Mar 03 15:29:35 sel01 gssproxy[896]: (OID: { 1 2 840 113554 1 2 2 })
Unspecified GSS failure. Minor code may provide more information, No
credentials cache found
Mar 03 15:29:35 sel01 gssproxy[853]: gssproxy[896]: (OID: { 1 2 840
113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more
information, No credentials cache found
Mar 03 15:29:35 sel01 gssproxy[853]: GSSX_RES_ACQUIRE_CRED( status: {
851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure.
Minor code may provide more information" "No credentials cache found" [
] } output_cred_handle: <Null>\
)
Mar 03 15:29:35 sel01 gssproxy[853]: [CID 11][2021/03/03 20:29:35]:
[status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x56413aeb64f0
(116)]: [0x7fe17c003370 (176)]
I can give you a much more detailed log if it would help.
Is anything in a level 3 log file (context_handle strings) confidential?
Jason.