Re: ACIs rely on multivalue attribute order (Was: are mulivalued attributes really unordered?)

["Pierangelo Masarati" <ando@sys-net.it>]

> Pierangelo Masarati wrote:
>>>>OpenLDAPaci: 1#entry#grant;r,w,s,c;[all]#group#cn=enterprise [..]
>>>>OpenLDAPaci: 2#entry#grant;r,w,s,c;[all]#group#cn=dallas [..]
>>>>OpenLDAPaci: 3#entry#grant;r,w,s,c;userPassword,mail; [..]
>>>>OpenLDAPaci: 4#entry#grant;r,s,c;[all]#group#cn=all [..]
>>>>            ^^^
>>>>AFAICS the prefixed numbers preserve the ACI evaluation order.
>>
>> [..] this is
>> a clear violation of the protocol and thus will not portable,
>
> Ordering is preserved by definition and proper handling of the ACI
> syntax (not LDAP syntax or protocol). See numbered prefix in the
> attribute values above. Ordering at protocol level is *not* assumed for
> ACIs.

I mean: if you (or the implementation...) shuffle them

OpenLDAPaci: 2#entry#grant;r,w,s,c;[all]#group#cn=dallas [..]
OpenLDAPaci: 1#entry#grant;r,w,s,c;[all]#group#cn=enterprise [..]
OpenLDAPaci: 4#entry#grant;r,s,c;[all]#group#cn=all [..]
OpenLDAPaci: 3#entry#grant;r,w,s,c;userPassword,mail; [..]

then nothing in the current code even looks at the first data to put them
back in order.  This is my understanding of what the current code does.

I agree the first field is essentially intended to order ACIs, and ACIs
are intended to be machine-writable rather than human-writable, so the
implementation could safely assume they're always ordered; however, if at
some point somebody decides to store multivalued attrs, for instance, in
stacks, then the evaluation would occur in reversed insert order unless we
take countermeasures which __ARE_NOT__ currently in place.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497