openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

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

Re: (ITS#5757) back-null returns an error when any critical extension is specified
by Kurt＠OpenLDAP.org 20 Oct '08

20 Oct '08

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. I would suggest simply updating the manual. "Searches return success" is refer to basic search operations (as requested by a search with no controls). -- Kurt

1 0

(ITS#5757) back-null returns an error when any critical extension is specified
by jclarke＠linagora.com 20 Oct '08

20 Oct '08

Full_Name: Jonathan Clarke Version: RE24 (and 2.3.x) OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi folks, Considering a setup like the following: 8<------------------------------------------------ database ldap suffix "dc=remote,o=base" subordinate uri ldap://ldap.remote.com overlay rwm rwm-suffixmassage dc=remote,o=base dc=remote database null suffix "o=base" overlay glue 8<------------------------------------------------ (I realize this is of course completely useless on it's own, but associated to other backends is quite useful - this simple example is to explain this bug report only) A search of scope sub on o=base will be passed to back-ldap, performed on the remote server and the results returned. If a non-critical control is passed with a search, back-null will pass it to back-ldap, and to the remote server, with success, returning results as expected with the control. However, if a critical control is passed in the same way, back-null returns the "12 Critical extension is unavailable" error, since back-null doesn't declare support for any controls. According to the slapd-null man page for back-null: "Searches return success but no entries". The following patch changes this so that back-null declares controls in the same way back-ldap and back-meta do, and passes critical controls on to any subordinate databases. In case they don't support the control, success is returned anyway, as the man page specifies. The patch: http://milopita.phillipoux.net/jonathan-clarke-20081020.patch (this a simple copy and paste from back-ldap/back-meta)

1 0

Re: (ITS#5754) Not able to download from mirrors
by Kurt＠OpenLDAP.org 20 Oct '08

20 Oct '08

On Oct 19, 2008, at 10:46 PM, asha.murugesapandian(a)accenture.com wrote: > Full_Name: Ashalatha Murugesapandian > Version: 2.4.12 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.36.210.72) > > > Hi, > > I am not able to download openldap from any mirror. It is showing > "Page can not > be displayed" message. Can you please let me know the solution to > download > OPENLDAP software? > > Regards, > Ashalatha Murugesapandian > > As downloading of files from our primary site and mirrors appears to be working just fine for others (including me), this appears to be a problem at your system/network. I suggest you contact your IT department for assistance/advice. -- Kurt

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