zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szalay-Bekő Máté <szalay.beko.m...@gmail.com>
Subject Re: Zookeeper and curator SASL authentication
Date Mon, 13 Jan 2020 16:17:37 GMT
Also please note, that the 'Configuration.getConfiguration().refresh()'
will reload only the jaas.config.
If you also need to reload the kerberos client config, then you can add the
"refreshKrb5Config=true" line to your jaas.conf file. This will trigger to
reload the krb.cfg file as well if needed.

I am just working on a PR where I had to use both of these:
https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a

Cheers,
Mate

On Thu, Jan 9, 2020 at 10:02 PM Damien Diederen <ddiederen@sinenomine.net>
wrote:

>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message