On Wed, 2021-03-03 at 16:28 -0500, Jason Keltz wrote:
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.
Great.
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 )
Is euid 1004 your user's uid ?
I wonder if there is a race between creation of the cache and NFS
access attempt.
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?
It may contain tokens, should be just encrypted data, but better not
post from production systems.
You can send it directly to me if you like.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc