openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5872) slapo-cloak
by hyc＠symas.com 27 Dec '08

27 Dec '08

ando(a)sys-net.it wrote: > Emmanuel Dreyfus wrote: >> Pierangelo Masarati<ando(a)sys-net.it> wrote: >> >>> That's my opinion, of course. I suggest you start from contrib/ and >>> then we'll vote for moving it to overlays/. >> How do I book an OID for the config database, for an overlay in contrib? >> Is it ok to just keep the comment in servers/slapd/bconfig.c? >> * OLcfgOv{Oc|At}:22 -> cloak > > Yes. Why did you skip :21, BTW? No, for contrib modules reserve the OID in contrib/ConfigOIDs -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Also, you shouldn't duplicate the entry until you find an occurrence of an attribute that needs to be hidden, otherwise you make slapo-cloak unnecessarily resource intensive. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

manu(a)netbsd.org wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >>> How do I book an OID for the config database, for an overlay in contrib? >>> Is it ok to just keep the comment in servers/slapd/bconfig.c? >>> * OLcfgOv{Oc|At}:22 -> cloak >> Yes. Why did you skip :21, BTW? > > Can't remeber why. I'll go back to 21. At a quick glance, you're leaking the callback containing the cloak response. You should remove (and free it) when called with REP_RESULT as sr_type, and add a slap_freeself_cb() cleanup hook. You won't notice the memory leak unless you build slapd with SLAP_NO_SL_MALLOC set, or unless your overlay operates within a slab memory intensive context. Configuration is leaking as well, I couldn't exactly trace where. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > > How do I book an OID for the config database, for an overlay in contrib? > > Is it ok to just keep the comment in servers/slapd/bconfig.c? > > * OLcfgOv{Oc|At}:22 -> cloak > Yes. Why did you skip :21, BTW? Can't remeber why. I'll go back to 21. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Kurt Zeilenga wrote: > > On Dec 27, 2008, at 2:46 AM, ando(a)sys-net.it wrote: > >> empty or "*" ; all user, except attrs that need to be explicitly req. >> "+" ; all operational >> <all including attrs that need to be explicitly requested> >> <...> > > I note that the specification of '+' does allow a server not to provide > all operational attributes. That is, a server is allowed to only return > some operational attributes when requested by name. ... based on how expensive their computation is. In fact, we do not exploit this too much in slapd(8), where '+' usually triggers operational all attributes evaluation. Probably, we should add the possibility to configure whether the most expensive are computed or not when not explicitly requested. > This is not so with '*' (or empty list). well, according to RFC4511, Section 4.5.1.8.: Client implementors should note that even if all user attributes are requested, some attributes and/or attribute values of the entry may not be included in Search results due to access controls or other restrictions. The restrictions we're discussing may well fit into this. > However, that said, I see no > particular issue with a server choosing to return a particular user > applications attribute only when requested by name. I see this simply > as an administrative restriction... and those are always allowed. Exactly. > (I also note that use of '*' (or empty list) and '+' should generally be > limited to requests formed by a human. It is bad (but all to common) > practice for application-specific directory clients to ask for > everything. They should really only ask for what they are prepared to > make use of. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by Kurt＠OpenLDAP.org 27 Dec '08

27 Dec '08

On Dec 27, 2008, at 2:46 AM, ando(a)sys-net.it wrote: > empty or "*" ; all user, except attrs that need to be explicitly req. > "+" ; all operational > <all including attrs that need to be explicitly requested> > <...> I note that the specification of '+' does allow a server not to provide all operational attributes. That is, a server is allowed to only return some operational attributes when requested by name. This is not so with '*' (or empty list). However, that said, I see no particular issue with a server choosing to return a particular user applications attribute only when requested by name. I see this simply as an administrative restriction... and those are always allowed. (I also note that use of '*' (or empty list) and '+' should generally be limited to requests formed by a human. It is bad (but all to common) practice for application-specific directory clients to ask for everything. They should really only ask for what they are prepared to make use of. -- Kurt

1 0

(ITS#5874) MMR does not work in refreshOnly
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando After updating tests/run.in from CVS (rev 1.59) and reconfiguring, executing test050 with SYNCMODE=ro results in a failure. The failure is not strictly reproducible, but it always occurred to me, either affecting one or another delete that is not propagated to all participants to the MMR pool. I've raised the sleep time, to make sure there's no chance replication did not occur yet. I wonder if refreshOnly makes any sense for a MMR pool. If it doesn't, it should not be allowed. If it does, deletes should be replicated correctly. p.

1 0

Re: (ITS#5872) slapo-cloak
by ando＠sys-net.it 27 Dec '08

27 Dec '08

Emmanuel Dreyfus wrote: > Pierangelo Masarati <ando(a)sys-net.it> wrote: > >> That's my opinion, of course. I suggest you start from contrib/ and >> then we'll vote for moving it to overlays/. > > How do I book an OID for the config database, for an overlay in contrib? > Is it ok to just keep the comment in servers/slapd/bconfig.c? > * OLcfgOv{Oc|At}:22 -> cloak Yes. Why did you skip :21, BTW? 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > That's my opinion, of course. I suggest you start from contrib/ and > then we'll vote for moving it to overlays/. How do I book an OID for the config database, for an overlay in contrib? Is it ok to just keep the comment in servers/slapd/bconfig.c? * OLcfgOv{Oc|At}:22 -> cloak -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: (ITS#5872) slapo-cloak
by manu＠netbsd.org 27 Dec '08

27 Dec '08

Pierangelo Masarati <ando(a)sys-net.it> wrote: > It is :). However, I think only generally useful things should go into > mainstream. As such, I remember some overlays moving from overlays/ to > slapd-modules/ and others moving the other way, based on their > generality and usefulness. The annoying thing is that the only added value of contrib/ is to make building more difficult. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs