openldap-bugs

openldap-bugs@openldap.org

1 participants
21046 discussions

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

28 Dec '08

manu(a)netbsd.org wrote: > Howard Chu <hyc(a)symas.com> wrote: > >> I suppose so. I put my stuff in there when I don't consider it worth my effort >> to autoconf-iscate it. Things like nssov only work with Linux, so there's no >> point in adding the overhead. Stuff in there really is of too limited use to >> warrant the full effort of maintenance that the core code gets. > > That means the added value of contrib/ is that it will only be > maintained by its contributor and will rot otherwise. > > Overlays that have been autoconf-ified could all reside in > server/slapd/overlays. Non-core thing would be disabled by default, and > would rot if not maintained by their contributors, as they are now... Didn't mean to start a holy war about contrib/ vs. overlays/. My intention was to isolate overlay development from autoconf-ing, until generality and usefulness demand for moving to overlays/. 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 28 Dec '08

28 Dec '08

Hallvard B Furuseth wrote: > ando(a)sys-net.it writes: >> On a related note, if this can be considered of general usefulness, LDAP >> specs would need to be changed in order to define a finer grain of >> attribute request; something like: >> >> empty or "*" ; all user, except attrs that need to be explicitly req. >> "+" ; all operational >> <all including attrs that need to be explicitly requested> >> <...> > > Would it be cleaner if slapo-cloak redefines the attributes to be > operational, or to behave as if they are? Maybe give them an > X-AS-OPERATIONAL extension? Or would that just mess up schema code, > things like attribute inheritance? I think things would mess up. The X-AS-OPERATIONAL could help, although it would result in a modification of otherwise standard-track schema items. Moreover, I see a number of features system administrators could ask for; e.g. hide attributes only when matching a URI (base, scope, filter), or based on size limit, or based on client's identity and so. In this case, I'd keep schema out. 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

(ITS#5875) sparc64/gcc-3.3 build fix
by manu＠netbsd.org 28 Dec '08

28 Dec '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD-4.0 URL: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/databases/openldap/pa… Submission from: (NULL) (213.41.141.172) NetBSD's pkgsrc has a 5 years old OpenLDAP patch that address a build problem on sparc64 with gcc 3.x (x <= 3). The build failure is caused by a bug in gcc. I think it would not hurt to commit this patch in OpenLDAP CVS: everything is guarded by macros, so it cannot cause any harm to unaffected systems, and the workaround has been tested by NetBSD people for 5 years.

1 0

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

27 Dec '08

Howard Chu <hyc(a)symas.com> wrote: > I suppose so. I put my stuff in there when I don't consider it worth my effort > to autoconf-iscate it. Things like nssov only work with Linux, so there's no > point in adding the overhead. Stuff in there really is of too limited use to > warrant the full effort of maintenance that the core code gets. That means the added value of contrib/ is that it will only be maintained by its contributor and will rot otherwise. Overlays that have been autoconf-ified could all reside in server/slapd/overlays. Non-core thing would be disabled by default, and would rot if not maintained by their contributors, as they are now... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

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

27 Dec '08

manu(a)netbsd.org wrote: > Pierangelo Masarati<ando(a)sys-net.it> wrote: > >> I'd see this overlay more appropriate for contrib/slapd-modules right >> now, until its functionality is considered of general usefulness, which >> doesn't seem to be the case right now. > > Do you think an overlay in the contrib directory could have its --enable > flag in top level configure? > My feeling about the contrib directory is that it is some kind of evil > swamp where things are much more difficult to automatically build for > inclusion in a package. I suppose so. I put my stuff in there when I don't consider it worth my effort to autoconf-iscate it. Things like nssov only work with Linux, so there's no point in adding the overhead. Stuff in there really is of too limited use to warrant the full effort of maintenance that the core code gets. -- -- 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 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

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