zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Diederen <ddiede...@sinenomine.net>
Subject Re: Zookeeper and curator SASL authentication
Date Thu, 09 Jan 2020 21:02:28 GMT

Hi Enrico,

> There is a method to force JAAS to reload the system property.
>
> Something like Configuration.getConfiguration().refresh()

Great to know!  Thanks!

> You have to call that method after changing the system property

Cheers, -D



> Il gio 9 gen 2020, 20:05 Damien Diederen <ddiederen@sinenomine.net> ha
> scritto:
>
>>
>> Hi Arpit, Máté,
>>
>> Arpit wrote:
>>
>> > The solution is to pass JAAS file
>> > with  -Djava.security.auth.login.config=/path/to/jaas.conf.
>>
>> Okay—good.
>>
>> > Using System.setProperty does not work for me.
>>
>> Ah, I see.  And I'm not surprised; I think Máté is on the right track:
>>
>> >> I also faced this exception not long ago. I think it is an edge case,
>> most
>> >> probably you have something else, but still... maybe it helps:
>> >>
>> >> I tried to write a unit test which dynamically generated multiple
>> >> jaas.conf files. Then I was setting the
>> >> java.security.auth.login.config system property to the config file I
>> needed
>> >> in the given testcase, and when I tried to establish a ZooKeeper
>> connection
>> >> in the unit test, I also got the same exception that you got.
>> >>
>> >> The problem was, that the security configuration file I referred in the
>> >> java.security.auth.login.config system property file was read only once,
>> >> then stored in memory. And it haven't got reloaded, even if the file (or
>> >> its path in the system property) changed.
>>
>> My understanding is that the property is read very early after "VM boot"
>> (the first time any class tries to access the java.security.Provider):
>> the resource it points to is parsed at that point, and the property
>> "never" checked again.
>>
>> (It *may* be possible to flush the "Spi" or something, but it's clearly
>> not the kind of usage it was designed for.)
>>
>> >> Maybe the best in this case is to
>> >> specify separate JAAS config sections for each tests and use a single
>> >> JAAS.conf file per JVM.
>>
>> That's probably the easiest if the set is enumerable.
>>
>> "Real dynamism" might require overriding the "Spi" or "Provider," but
>> that's probably overkill for a few tests.
>>
>> (Now that I think of it… our tests are already run under the JMockit
>> agent, so live-patching JAAS methods using mockit.MockUp might be
>> another option :)
>>
>> Anyway.  It looks like setting the property externally worked for Arpit.
>>
>> Cheers, -D
>>

Mime
View raw message