[15905] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #8651] kinit -kt KDB: Cannot find/read stored
daemon@ATHENA.MIT.EDU (Richard Basch via RT)
Sun Mar 18 15:53:36 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Richard Basch via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8651@krbdev.mit.edu>
Message-ID: <rt-8651-48306.5.2862096115458@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8651'":;
Date: Sun, 18 Mar 2018 15:53:30 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: multipart/mixed; boundary="===============2647253158829575970=="
Errors-To: krb5-bugs-bounces@mit.edu
--===============2647253158829575970==
I see a second open of the fd in the strace… apparently, in some circumstances, it is resulting in a double-read.
> On Mar 18, 2018, at 3:51 PM, Richard Basch <basch@alum.mit.edu> wrote:
>
> This might indicate it did a double read of the config file where the data was already consumed… second read may have failed.
> But why sporadically?
>
>> On Mar 18, 2018, at 3:44 PM, Richard Basch <basch@alum.mit.edu> wrote:
>>
>> There was one other small nuance in my test… I used a custom kdc.conf, specified as a bash sub-command:
>>
>> KRB5_KDC_PROFILE=<(printf …) …
>>
>> That said, the strace showed it reading from /dev/fd/63 with data returned such as the database_name, so there is no obvious failure on the shell to provide the fd or that the fd was inaccessible. (The only reason I use this syntax to generate a custom KRB5_KDC_PROFILE is to circumvent defining the kadm5_dict_file and loading some of the kadm5 hooks which don’t apply for the kinit operations - this method significantly improves the performance, when it doesn’t sporadically fail.)
>>
>>
>>> On Mar 18, 2018, at 3:31 PM, Greg Hudson via RT <rt-comment@KRBDEV-PROD-APP-1.mit.edu> wrote:
>>>
>>> I tried running the same script (inside "make testrealm", and gwithout
>>> the env var settings since that's already taken care of) and
>>> unfortunately couldn't reproduce the issue, with either master or 1.15.
>>>
>>> Knowing that it was trying to read the stash file from the unconfigured
>>> location is interesting; it suggests perhaps an earlier failure to read
>>> $KRB5_KDC_CONFIG or something. But I still can't come up with a theory
>>> as to what the bug might be.
>>> _______________________________________________
>>> krb5-bugs mailing list
>>> krb5-bugs@mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/krb5-bugs
>>
>
--===============2647253158829575970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
--===============2647253158829575970==--
