[Date Prev][Date Next]
Re: passwd extop backend selection (ITS#2851)
> I think this patch should not be applied. (redirected discussion to
> The problem you are trying to solve is internal to slapd(8) and hence
> shouldn't be addressed without regard to what's on the wire. That is,
> the problem here is purely with slapd(8) management of which backend(s)
> is associated with the current LDAP association.
> While we could change slapd(8) to support changing of selected (by
> userIdentity) passwords, then that's what slapd(8) has to do when a
> userIdentity is provided. That is, it must change the password
> associated with userIdentity. That cannot be assumed to be the same
> user as that of the current LDAP association.
I don't quite understand your comment. Can you elaborate
on "LDAP association"?
Moreover, my point was quite "smooth": if slapd serves
"dc=a,dc=com" in one database and "dc=b,dc=com" in another
database, then if "uid=foo,dc=a,dc=com" tries to change
"uid=bar,dc=b,dc=com"'s password, which should be legal
as soon as "uid=foo,dc=a,dc=com" authenticated and has write
access to "uid=bar,dc=b,dc=com"'s password, then slapd
currently looks up "uid=bar,dc=b,dc=com" in "dc=a,dc=com",
which gives no such object.
My change uses "uid=bar,dc=b,dc=com"'s naming context to
select the appropriate backend.
The point I was concerned with is: is this acceptable?
I think it is, but dealing with secrets makes me think
twice before going straight down the path ;)
> At 10:47 PM 11/30/2003, email@example.com wrote:
>>Full_Name: Pierangelo Masarati
>>OS: Linux RH
>> Submission from: (NULL) (126.96.36.199)
>>Submitted by: ando
>>passwd_extop() in servers/slapd/passwd.c uses
>> op->o_conn->c_authz_backend (the authorizing backend) to operate the
>> password change. This patch uses the ID field in reqdata, if any, to
>> select the appropriate backend, in view of using passwd_extop across
>> backends in glued backend pools.
>>Any drawback or security issue?