[Date Prev][Date Next]
Re: uniqueMember and nameUID* issues (ITS#3210)
Another related issue: currently, we assume that a nameUID string
terminated by "'B" contains an ID; I think that unless we're able
to isolate a terminal part made of an unescaped "#" followed
by "'", a bistring, and terminated by "'B" we should treat the whole
string as a DN unless explicitly violating DN string encoding.
I note that "cn=Foo#'1'B" is perfectly legal as a DN
as well, since the character "#" doesn't need to be escaped
except at the beginning of the value part of an AVA in a DN.
So, based on the string representation, a nameUID is valid
as a DN as well. As such, I think we should remove the test
for an escaped number sign when extracting the UID part of a
nameUID, and treat it as a DN instead of failing when
cn=Foo#'1'B // legal DN + UID = 1
cn=Foo#1'B // legal DN?
cn=Foo\#'1'B // legal DN without UID ("#" may be escaped)
cn=Foo#'2'B // legal DN?
cn=Foo#2B // legal DN?
> Full_Name: Pierangelo Masarati
> Version: HEAD, 2.2
> OS: Linux (irrelevant)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (184.108.40.206)
> There are issues with the uniqueMember attribute. Adding an optional UID
> (i.e. a suffix of the form "#'<uid>'B" to a DN-style value) causes an
> in dnPretty because the DN is not NULL terminated (which is a bit old and
> overconservative, but indicates a problem in any case, since we still want
> to be
> able to use generic DNs in string representation as NULL terminated
> Moreover, the numeric ID is accepted whatever string it uses, whilke its
> requires it be a bitstring (i.e. '1' or '0', with the lead digit a '1'
> the whole value is '0').
> Finally, the uniqueMemberMatch is a bit optimistic since it does memcmp()
> on the
> UID part even if the length of the UIDs is different.
> A patch is coming.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497