klist -t opening $HOME/.rnd

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

klist -t opening $HOME/.rnd

Harald Barth-2

I just observed that "klist -t" was very slow.

When I did an strace I observed that it tried to open $HOME/.rnd and
that operation did take time to get refused.

Looks like this is because of the usage of some openssl random number
function which is used by this operation.

But why do I need to initialize a random number function just to
determine if the ticket in the file ticket cache is valid?

Seems like waste of resources to me.

Ok, I can surpress this by setting

    export RANDFILE=/tmp/pigz_had_wingz/for_sure_/this_week

but that interferes probably with other stuff.

Harald.
Reply | Threaded
Open this post in threaded view
|

Re: klist -t opening $HOME/.rnd

Greg Hudson
On 03/15/2018 05:38 AM, Harald Barth wrote:> But why do I need to
initialize a random number function just to
> determine if the ticket in the file ticket cache is valid?
>
> Seems like waste of resources to me.

Heimdal's krb5_init_context() intentionally initializes the random
number generator, so that subsequent uses don't have to worry about
error checking.

I think that side of the design is fine, but a library PRNG probably
doesn't need to interact with a seed file in this day and age.  That
decision is under Heimdal's control, not OpenSSL's; removing the code
ifdef'd NO_RANDFILE in lib/krb5/crypto-rand.c would suffice.

(MIT krb5 could also stand to simplify its PRNG, although it doesn't
have this particular problem.)
Reply | Threaded
Open this post in threaded view
|

Re: klist -t opening $HOME/.rnd

Harald Barth-2

> I think that side of the design is fine, but a library PRNG probably
> doesn't need to interact with a seed file in this day and age.

So if we remove the blocks protected by NO_RANDFILE
we get

seed_something(void)
{
    /* Calling RAND_status() will try to use /dev/urandom if it exists so
       we do not have to deal with it. */
    if (RAND_status() != 1) {
        /* TODO: Once a Windows CryptoAPI RAND method is defined, we
           can use that and failover to another method. */
    }

    if (RAND_status() == 1)     {
        return 0;
    } else
        return -1;
}

Which boils down to

seed_something(void)
{
    /* Write something more fancy if a Windows CryptoAPI RAND method is
       available as an alternate fallback but until that just convert
       the return value */
    return (RAND_status() == 1) ? 0 : -1 ;
}

Should we make that simplification (I have no specific opinion about
the "?" operator, if/else according to the original code is fine as
well)?

Harald.

Reply | Threaded
Open this post in threaded view
|

Re: klist -t opening $HOME/.rnd

Harald Barth-2
In reply to this post by Greg Hudson

> Heimdal's krb5_init_context() intentionally initializes the random
> number generator, so that subsequent uses don't have to worry about
> error checking.

The more I think about it, the more wrong I think this is. We are
talking about a library call used by "klist" here. Klist should work
without even any random number source available. Unfortunately klist
needs to read krb5.conf (and other possible config locations) just to
figure out where to find the credential cache, otherwise not even that
would be needed to do its work.

But still krb5_init_context does more than documented. Man page says
"initialize structure" and "read conf file", nothing more and I can
not see why kinit would need more or why any program would rely on the
additonal actions like quote "krb5_init_context() will get one random
byte to make sure our random is alive." (see comment in source) when
it's not documented at all. So I'd say krb5_init_context should stick
to what it is documented to do and if apps need randomness to work
they should call krb5_generate_random which is the function for it.

Otherwise we can add "do we have network connectivity" into
krb5_init_context just because we may need that as well in the program
later (ok, that's a biut exaggerated, but you get the point ;-) ;-)

Harald.