[Date Prev][Date Next]
Re: SASL OTP and syncrepl
> Pierangelo Masarati <email@example.com> wrote:
>> Not necessarily. Every write to a well-configured replica should be
>> rejected with a referral. The chain overlay will intercept the referral
>> and chase it, applying the modification to the master. You need to
>> check why no referral is returned, since the master's value eventually
>> overrides the replica's. Either the configuration uses an identity that
>> bypasses shadow checks (like the updatedn) or some SASL-related code
>> (slap_auxprop_store?) is performing an internal modification with some
>> special flag that bypasses shadow checks.
> I beleive the offending code is in
> It seems we use the authc Id:
> But there is no special flags:
> mod->sml_flags = 0;
> Nothing in the logs on the master. On the client I have this at bind
> SASL [conn=219246] Error: SASL error opening password file. Do you have
> write permissions?
> SASL [conn=219246] Failure: Could not open db for write
> But it happens all the time, OTP being used or not.
I think this is not related. This definitely looks like the known issue
that libsasl always tries to check the sasldb, as soon as libsasldb.so is
I've never used SASL OTP with slapd, so I'm not aware of all details, can
you post how you configured the whole stuff?
What I suspect, in your issue, is that slap_auxprop_store() writes
something locally, bypassing the fact that it is writing on a shadow
database. Whether having authentications on a shadow database modify the
master is the correct behavior or not, it is not entirely clear to me.
Apparently, this is a requirement for OTP, but it might be undesirable in
other cases. Consider for example all the issues related to replicating
(or not replicating) attributes specific to password policy... things need
to be at least discussed to figure out all the details and implications.