openldap-devel

openldap-devel@openldap.org

1431 discussions

ITS#4556 ACLs for new entries
by Howard Chu 21 Sep '07

21 Sep '07

Revisiting this topic - DITStructureRules are not a solution to this problem. E.g. in cn=config, now that you can grant write access to arbitrary users, it becomes pretty critical to be able to prevent certain users from creating certain types of objects. E.g., I may want to allow someone to be able to create one type of child object under cn=config (e.g., databases) but not some other type (e.g., modules). So at the very least we need to be able to use ACL filters on new entries. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

dynamic groups
by Michał Szulczyński 18 Sep '07

18 Sep '07

Hello, My name is Michał Szulczyński, and I'm a student at Warszawska Wyższa Szkoła Informatyki in Poland. I'm on a practice at the company where Aleksander Adamowski works. As he said, I will try to implement dynamic list member 'caching'. The general idea is to "materialize" the member attribute of the dynamic group using existing static attribute values infrastructure (including indexes) and update them automatically when there is a add/modify/modrdn/delete operation on an object that matches the dynlist memberURL filter. The operation of dynlist overlay would be identical as it is now without specifying an additional dynlist configuration option. The plan is to, depending on the additional, optional dynlist-attrset configuration parameter, grab the dynamic list entries for that dynlist configuration from the database, and put them into a memory-resident list (which would hold all the dynamic groups that we are interested in, ie. the ones with the additional configuration option set). When there is a add/mod/modrdn/delete operation on any entry, we would check this list for a matching dynlist filter, and add/modify/delete the member attribute of the dynamic list for that entry. Much like a static group, but with automated addition/deletion to/from it, effectively making it a dynamic group. Manual updates to the member attribute would be prevented and would raise an error. First, in addition to dynlist_info_t we would need to hold the pointer to our memory-resident dynamic group list per dynlist overlay instance. That's for speed optimization, since searching for all dynamic lists on each update operation would have a huge performance impact. As we can only hold only one backend-specific config data in Operation->o_bd->bd_info->on_bi.bi_private, we wold need to hold both pointers (dynlist_info_t and the pointer to our list) in an additional struct, and store that. But this method would mean changing much of the existing codebase, and I don't know if that would be good. If there would be another place where we could store the pointer to the dynamic group list, that would be better. Second, I would like to know if there is a function to test whether one DN is contained in another DN (i.e. one DN is a descendant to another DN). I need this to compare the base DN of the dynamic group, and the added/modified/deleted/modrdn'ed entry (eg: if the entry DN <uid=test,l=City,ou=People,o=MyOrg> is in the dynamic group's member URL's base DN <ou=People,o=MyOrg>). I think that comparing the normalized DN's stringwise backwards from the strings' end would work, but I'm not sure. Third: * can we do an add-or-replace with BackendDB->be_modify * when doing a LDAP_MOD_DELETE on a single attribute's value can we ignore a case where that attribute value does not exist in the entry (so we can avoid checking for its presence and save an unnecessary read operation)? -- Michał Szulczyński Praktykant Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.

4 7

Re: dynamic groups
by Michał Szulczyński 18 Sep '07

18 Sep '07

Howard Chu wrote: > One last question that may need an answer: > what groups does user X belong to? > > Obviously you need to perform a search to determine this. And with the current > indexing mechanisms, dynamic groups will fail to be matched since they don't > actually contain an indexed static member list. If this is the question you're > trying to answer, the solution is simply to maintain a list of dynamic group > objects (as your current code already does) but not to populate them. Instead, > just use a search response callback and see if "member" is a part of the > filter. If it is, iterate through the dynamic groups and test the entry whose > DN is in the filter assertion against all of the dynamic group filters. This > solution will use far less memory than your approach, and it will run > efficiently for just about all use cases. This was actually the first idea we thought of, we concluded that it would slow the search down, because then the algorithmic complexity of the search would be O(n), with n as the number of dynamic groups. We think this would be somewhat against the idea of LDAP directories, where the number of search operations far outweigh the number of updates. It is a trade-off between update speed and search speed, but we think that the search speed is essential, and the update operations are not our primary concern speed-wise. -- Michał Szulczyński Praktykant Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. +48 603-338-373 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.

2 1

imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 18 Sep '07

18 Sep '07

Hello I modified my patch to slapo-constaint. The constraint can now be written as a LDAP url, which allows much more flexibility: Usage example: constraint_attribute title uri ldap:///cn=titlecat,dc=example,dc=net?title?sub? Here is the new patch: ftp://ftp.openldap.org/incoming/manu-070918.patch Comments are welcome. I'll now write a man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by Howard Chu 18 Sep '07

18 Sep '07

manu(a)netbsd.org wrote: > Gavin Henry <ghenry(a)suretecsystems.com> wrote: > >> It would be best to move this dicussion to openldap-devel(a)openldap.org now. > > Let's go... > > Summarry: I've added a new feature to slapo-constraint for constraining > a value attribute the the existing values of another attribute. The idea > is that you can have a catalog of allowed values (eg: for titles: Mr, > Mrs, Miss) and constraint an attribute to these values > > Before working further on this patch (style, dod), I'd like some feeback > on: > 1) the way it's implemented: is there rought bugs, or is the logic fine? I haven't looked at the patch yet. > 2) configuration syntax: do we keep this one or do we swtich to > something else? Something like constraint-reference attr1 attr2 might be better. For simple directives, it's better to use positional parameters and no tag words. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

Trouble with Bind/overlays/callbacks
by Howard Chu 17 Sep '07

17 Sep '07

In slapd just about all of the operation handlers send their results from the backend directly to the client. The notable exception is for the Bind operation, which sends failures directly to the client, but has to return successes to the frontend to allow final processing to occur there. This difference causes a fair bit of complexity when writing Bind handlers in backends and overlays. In 2.3 we ran into other sequencing issues that could only be solved by moving some of the Bind cleanup into a callback (connection_bind_cb). We have an opportunity now to move all of the postprocessing into that callback, allowing us to remove all special case handling of Binds in the backends and overlays. Of course, making this change will touch every backend that handles Bind operations. It may impact overlays that intercept Binds as well. In particular, overlays that insert response callbacks on Bind operations can potentially break in the current code. I.e., if an overlay inserts a callback at the head of the stack (instead of at the end) then currently it will simply not get called in the case of a successful Bind, because the overlay framework tears down the callback stack before it returns to the frontend. If the callback was inserted using malloc'd memory then it will cause a memory leak as well. I plan to file an ITS on this for RE24, not sure how soon I'll get to the actual changes though. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: commit: ldap/doc/man/man5 slapd-meta.5
by Pierangelo Masarati 13 Sep '07

13 Sep '07

ando(a)OpenLDAP.org wrote: > HEADS-UP: now the list of URIs is better set by using separate arguments The new behavior should be the only documented one. It allows to get rid of the long-lasting, quite annoying "tabs-separated URI list" issue. The old syntax is fully recognized, but it should just be forgotten. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

rfc45xx in RE23?
by Gavin Henry 13 Sep '07

13 Sep '07

Hi all, Why don't we have any 45XX rfcs in doc/rfc/ ? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

5 8

Fast Bind
by Gavin Henry 13 Sep '07

13 Sep '07

In our docs, should we use the term "Fast Bind", i.e. when a client supplies a full DN and also a password, or is it misleading? I've seen this referenced in other documentation and Cyrus SASL. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

3 5

http://www.openldap.org/devel/admin/ updates?
by Gavin Henry 07 Sep '07

07 Sep '07

Dear all, Is it possible to delegate write access to the website? I'd like to put the latest updates at http://www.openldap.org/devel/admin/ rather than suretec.org Thoughts? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel