openldap-bugs October 2008

openldap-bugs@openldap.org

36 participants
187 discussions

Re: (ITS#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The latest draft I can find (14 February 2007) states that >> >> Clients MUST provide a >> criticality value of TRUE to prevent unintended modification of the >> directory. >> >> As a consequence, I think the server could reject instances of this control >> with a criticality of FALSE, to prevent its unintended use. > > RFC 2251 allowed that (or could be read as alllowing it), but > RFC 4511 deliberately does not, after long discussions on ldapbis. OK, backing out my latest commit. 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#5758) NO-OP control criticality
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

ando(a)sys-net.it writes: > The latest draft I can find (14 February 2007) states that > > Clients MUST provide a > criticality value of TRUE to prevent unintended modification of the > directory. > > As a consequence, I think the server could reject instances of this control > with a criticality of FALSE, to prevent its unintended use. RFC 2251 allowed that (or could be read as alllowing it), but RFC 4511 deliberately does not, after long discussions on ldapbis. -- Hallvard

1 0

(ITS#5758) NO-OP control criticality
by ando＠sys-net.it 20 Oct '08

20 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The latest draft I can find (14 February 2007) states that Clients MUST provide a criticality value of TRUE to prevent unintended modification of the directory. As a consequence, I think the server could reject instances of this control with a criticality of FALSE, to prevent its unintended use. However, OpenLDAP's slapd currently tolerates a criticality of FALSE, and OpenLDAP clients allow users to use this control with a criticality of FALSE. I think the clients need to be fixed, and the server should prevent this improper use. Also, the server should check whether the control is used with operations not indicated in the draft (i.e. non-write ops). p.

1 0

Re: (ITS#5625) memberOf search ACLs
by ando＠sys-net.it 20 Oct '08

20 Oct '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > >>From thread on opendlap-technical: > >> Hmm, I have the module loaded globally - perhaps I need a global rootdn >> of some kind defined? >> >> I have one per-database (now), but the documentation strongly encourages >> one not to have a rootdn at all. > > The fix was to define rootdn globally (as the module operates globally), > and then to give it explicit manage access in an ACL. eg > > access to dn.subtree="${DOMAINDN}" > by dn=cn=samba-admin,cn=samba manage > by dn=cn=manager manage > by * none > > rootdn cn=Manager > > Adding a rootdn to each database then quashed the warnings about 'rootdn > can always manage'. > > Otherwise, if I had 'by * read' then this also allowed the module to operate > correctly (but without the secrecy I desired) Few considerations: 1) having a rootdn in the global database (technically, in the frontend database) is not a bad thing, since it manages no data. Moreover, having a rootdn without password means that unless anyone can authorize as it (authzTo, authz-regexp and so) there is no way anyone can take that identity. As a consequence, it's there only for the purpose of performing internal operations with a privileged identity. We have discussed many times about the possibility to define a per-operation, possibly per-database flag that states the operation is being performed as a privileged identity, but so far we sticked with the rootdn as the client's identity. What comes to my mind right now is that we could define special interfaces for internal operations, something like sockurl=privileged:// to indicate internal operations; in those cases, an otherwise anonymous operation could be identified as privileged and thus bypass access control much like it would without the need to set a rootdn. 2) you don't need to add "by dn=cn=manager manage" to global ACL rules, since that's implied. This allows you to get rid of the warning messages. You'll need to add it to rules within each database, unless cn=manager is also the rootdn of those databases. 3) adding "by dn=cn=samba-admin,cn=samba manage" to all access rules can be annoying, but that's the right way, IMHO, to deal with your specific problem; you could work it around by adding a rule like access to * by dn=cn=samba-admin,cn=samba manage by * break early enough in each database's ACLs (right after the rule that allows anonymous to bind :) This rule seems a bit to open, since it gives cn=samba-admin,cn=samba privileges comparable to those of a global rootdn. Perhaps you want to restrict them to what data is actually pertinent to Samba4? 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#5632) "overlay" directive listing in slapd.conf misleading
by ando＠sys-net.it 20 Oct '08

20 Oct '08

hyc(a)symas.com wrote: > And the frontendDB was created after > overlays were first designed; the docs just haven't caught up to this fact yet. Just to note: the frontend database (use of a backend structure to collect frontend operations, adding an extra level of indirection in operations handling) was expressly designed to allow overlays to be stacked before database selection and selected operations handling. The main driver was slapo-chain(5) used to intercept referrals returned by the frontend when one tries to write to a shadow database, and slapo-rwm(5) to intercept requests and rewrite their DN, in order to be able to interfere with database selection. 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#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

A different fix is in HEAD. Please test. 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#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by ando＠sys-net.it 20 Oct '08

20 Oct '08

toby(a)inf.ed.ac.uk wrote: > Full_Name: Toby Blake > Version: 2.4.11 > OS: Scientific Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.115.7.181) > > > Hello, > > Caching of (more complex) lookups doesn't seem to work correctly using > openldap 2.4 and slapo-pcache. > > Identical set-ups, one using openldap 2.3.43 and one using openldap > 2.4.11 (+patch for ITS #5665). Trivial testing of 2.4.12 suggests > that the problem remains. The issue is confirmed. I could reproduce it with a much simpler configuration: overlay pcache proxycache bdb 100 2 6 1m proxyattrset 0 uid proxyattrset 1 cn proxytemplate "(&(objectClass=)(uid=))" 0 1m 1m proxytemplate "(uid=)" 1 1m 1m Note that swapping the attrsets and templates does not affect it: the template with the simple filter works, while the other doesn't. I was unable to detect the root cause, but it seems to be related to query confinement, where something about the first filter does not allow to store the second query, since the first bit, (objectClass=x), is identical in both queries. Note that swapping the simple filters, making the "unique portion come first, cures the problem: overlay pcache proxycache bdb 100 2 6 1m proxyattrset 0 uid proxyattrset 1 cn proxytemplate "(&(uid=)(objectClass=))" 0 1m 1m proxytemplate "(uid=)" 1 1m 1m 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#5755) Schema file not always converted to LDIF and slapdwon't restart
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

I wrote: > Possibly that should wait for OpenLDAP 2.5 though, and just log a > warning for now. ...though -f file -F dir should fail, of course. -- Hallvard

1 0

RE: (ITS#5755) Schema file not always converted to LDIF and slapdwon't restart
by h.b.furuseth＠usit.uio.no 20 Oct '08

20 Oct '08

The problem is the 8-bit Latin-1 character in the certificate's DESC. It works if you convert the schema file to UTF-8. Slapd should have refused to start with a non-UTF-8 attribute DESC. Possibly that should wait for OpenLDAP 2.5 though, and just log a warning for now. -- Hallvard

1 0

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by ando＠sys-net.it 20 Oct '08

20 Oct '08

Kurt(a)OpenLDAP.org wrote: > On Oct 20, 2008, at 7:55 AM, jclarke(a)linagora.com wrote: > >> In case they don't support the control, success is >> returned anyway, as the man page specifies. > > That may very well violate the control's specification. > >> In case they don't support the control, success is >> returned anyway, as the man page specifies. Probably, a reasonable approach would be to actually implement support for well known controls. In most cases, its implementation would be trivial (i.e. ignore them), but it would be done in a consistent manner. For example: support for manageDSAit, pr, vlv consists in ignoring them. Support for proxied authorization is dealt with by the frontend. And so on... 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

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2008