[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
How to make OpenLDAP use random (v4) UUIDs in entryUUID attribute
- To: openldap-technical@openldap.org
- Subject: How to make OpenLDAP use random (v4) UUIDs in entryUUID attribute
- From: dorian taylor <dorian.taylor.lists@gmail.com>
- Date: Tue, 28 May 2013 09:42:08 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1KlhghkDP5e9NYrn771h4SH5DXtB1kxdjnwz9cwrRkk=; b=E4lLmwQLZ9jlBAvhe9RGMFRJhHgdgbbKYamLwlg9s7IJygUCOq2AM3BM+iYw9vzvYn VlxAWfHHfXYOU985KQxmOkZq8xEwxlBBv71aM7sMeU5DNY8q9ewET61TYj55zGevm/G8 egEB20DaccJvhdv16yEim8ZLjui9XvYAEz6M+6LgQUyrTmQhsErK685z3JL0oUUsNcIx 7449Ng11pev7KVfeWRNLuvLzAZV6BLbx+aDKUoWt9YHJGeIWHA/J1JA8tZHo3x4VdAga e3VH9vF/5kEkq48lEeLT+YGhi2BDznAec7Ht8uqFIxokKo8TXPaCrfelElSIpSE/70Ln pRaw==
Hello,
It is my understanding that OpenLDAP keys its entries on UUIDs under
the hood. I have a system that makes extensive use of UUIDs as
canonical (and sometimes public-facing) identifiers, and would like to
tap into the UUIDs generated for the objects in the LDAP directory for
certain operations over those objects. The problem is I'm using type 4
(random) UUIDs [1] everywhere, and OpenLDAP uses type 1 (time-based).
It is important to the system to some extent that these identifiers be
resistant to sequencing. As such, they really ought to be random.
Since it hasn't been deployed in production yet, the sanest course of
action seems to be to bend OpenLDAP to comply. (The alternative would
be to maintain a dictionary of some kind, which I'm not keen about.)
A survey of the code is as such: OpenLDAP doesn't appear to care which
version of UUID it uses save for the generator function itself. The
util library is hardcoded [2] to use type 1, and the entryUUID
attribute itself is constrained in the schema [3] to not permit
modification (where "modification" ostensibly also extends to adding
new records). I'm not too familiar with the source but at a glance it
appears to accommodate an entryUUID attribute as input [4].
I guess my question is: what's the best strategy?
* Relax NO-USER-MODIFY on the entryUUID schema entry and set it at the
application layer (easiest but most prone to problems)
* Hack uuid.c to use uuid_generate_random instead of uuid_generate
(easy, but introduces a maintenance problem)
* Create an overlay (no idea where to start but can figure it out)
* Figure out some way to make the UUID version configurable and send a
patch upstream (most work and would it even be desirable?)
Links:
1) http://tools.ietf.org/html/rfc4122#section-4.4
2) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/liblutil/uuid.c;h=f073d40dfdd2bdc0fa1ab40787724a751ae229de;hb=HEAD
3) http://tools.ietf.org/html/rfc4530#section-2.4
4) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/slapd/add.c;h=b46053d67065f1fc74c15157c198d6efd1201b68;hb=HEAD#l639
--
Dorian Taylor
http://doriantaylor.com/