SCIENTIFIC-LINUX-DEVEL Archives

March 2017

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Pat Riehecky <[log in to unmask]>
Reply To:
Pat Riehecky <[log in to unmask]>
Date:
Thu, 30 Mar 2017 13:18:38 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
Thanks for the report!  And the follow up documentation!

Pat

On 03/30/2017 12:56 PM, Orion Poplawski wrote:
> Appears to be an interaction between the HTTP and nfs-client configuration.
> I've made a note of it in my response here:
>
> http://serverfault.com/questions/775068/gssproxy-apache-httpd-as-nfs-client-centos7
>
> SL7 package is fine.  I made the mistake of testing rhel7 with a different user.
>
> On 03/30/2017 08:53 AM, Pat Riehecky wrote:
>> Oh my.
>>
>> Thanks for the report, let me know if a rebuild fixes the issue.  If so we can
>> get an official reissued package put together.
>>
>> Pat
>>
>> On 03/29/2017 06:20 PM, Orion Poplawski wrote:
>>> I'm still seeing the gssproxy issue mentioned in this bug:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1414302
>>>
>>> where gssproxy doesn't look in /var/lib/gssproxy/clients/%UID.keytab for a
>>> valid keytab for non-root users.
>>>
>>> Bad strace (SL7.3) looks like:
>>>
>>> [pid  4528] close(15)                   = 0
>>> [pid  4528] gettimeofday({1490828550, 957971}, NULL) = 0
>>> [pid  4528] geteuid()                   = 0
>>> [pid  4528] open("/var/lib/gssproxy/clients/krb5cc_48", O_RDONLY|O_CLOEXEC) =
>>> -1 ENOENT (No such file or directory)
>>> [pid  4528] open("/var/kerberos/krb5/user/0/client.keytab", O_RDONLY) = -1
>>> ENOENT (No such file or directory)
>>> [pid  4528] writev(2, [{"gssproxy[4524]: (OID: { 1 2 840 113554 1 2 2 })
>>> Unspecified GSS failure.  Minor code may provide more information, No
>>> credentials cache found\n", 142}], 1) = 142
>>>
>>> i.e. looks first for active credential cache for the userid (48 in this case),
>>> but then a keytab for uid 0 and in the default kerberos location, not in the
>>> location specified in /etc/gssproxy/gssproxy.conf.
>>>
>>> Good strace (RHEL7.3) looks like:
>>>
>>> [pid   537] close(15)                   = 0
>>> [pid   537] gettimeofday({1490822814, 63838}, NULL) = 0
>>> [pid   537] open("/var/lib/gssproxy/clients/krb5cc_14", O_RDONLY|O_CLOEXEC) =
>>> -1 ENOENT (No such file or directory)
>>> [pid   537] open("/var/lib/gssproxy/clients/14.keytab", O_RDONLY) = -1 ENOENT
>>> (No such file or directory)
>>>
>>> I didn't set up a keytab in this case, but you see that it looked for the
>>> correct file - and didn't call geteuid().
>>>
>>> I'm not sure what's going on here.  Perhaps there was a build ordering issue
>>> with the SL7.3 package builds.  I'm going to try rebuilding the SL7.3 packages
>>> and see if that helps.  Just a heads up for now before I leave for the day.
>>>
>>>
>

ATOM RSS1 RSS2