openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by jonathan＠phillipoux.net 14 Apr '09

14 Apr '09

Full_Name: Jonathan Clarke Version: 2.4 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20090414.patch.1 Submission from: (NULL) (213.41.243.192) Hi, As noticed with Gavin on IRC, the Admin Guide doesn't have any obvious instructions on converting from old file format slapd.conf to new cn=config directory based conf - these instructions are only in the slapd-config(8) man page. Please see above patch for a suggestion to incorporating it into the admin guide. I have taken some liberties with the formatting, please feel free to amend if you like. I did put this in a top-level (H2) section, although it's short, mainly to make it obvious in the guide's contents. Any feedback is most welcome, particularly if this needs to be more detailed :) Regards, Jonathan

1 0

(ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: linux URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein I've had two cases where a delete operation was performed on the master without being replicated to its consumers, which so far appear to be cases of possible connection lost (abandon) race conditions. The log (level: stats) shows the "DEL" message of the entry, immediately followed by a "closed (connection lost)" message on the connection. Note: No "RESULT" message was logged. I haven't looked very much into this, but my theory so far is that syncprov skipped replicating of the delete op after noticing the abandon resulting from loosing the connection, even though the delete had already taken place in the local database. That it happened after a delete op might very well have been a coincident, this possible race could exist after any modify op for all I know. Do we need some sort of o_committed flag that can be used to prevent o_abandon from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with multiple values, including "too late"? Rein Tollevik Basefarm AS

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

abartlet(a)samba.org wrote: >> The only problem I see in defining such an attribute is that its >> syntax should allow the value of any syntax, so it should probably be >> octetString or something like that. =20 > > I think the AD document I reference explains that only some attributes > can be an RDN, so it limits them to those with a unicode string > representation I suppose.=20 OK, I coulnd't follow up to the document you cited. > There is another attribute that follows the 'type' of RDN btw (never > seen it used, but it's in the docs).=20 > >> From the implementation point of view, what operations should it be >> used for? If you only need it to be returned with searches, and to be >> compared, then the implementation would be trivial (it could be >> dynamically generated, much like entryDN, as far as I can tell). If >> you need to search for it, namely use it in a filter, then it might be >> better to store it in the database. This would require to handle add >> and modrdn, forbid modify, and nothing else. > > Like entryDN, we need to be able to search on it, so it should probably > be persistent. Ok. Unlike entryDN, which is not persistent but evaluated on the fly based on dn2id indexes, unless we hardcode this in slapd (don't think so) we need to make the attr persistent. It's on the todo list. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

David wrote: > So, we're still in dispute, as far as if this is a real bug or not? It seems to be a bug in the design of how data is gathered in view of ACL evaluation. Or better, overlay design invalidated an assumption that was valid when the only database type available passed the entire entry to ACL evaluation *before* entry massaging. Yes, it's a bug. 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#6058) slapcat aborts on a double free
by luca＠OpenLDAP.org 14 Apr '09

14 Apr '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Slapcat on a slapd instance using rwm overlay, aborts with: *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** To simulate it's enough a slapd.conf containing something like # Load dynamic backend modules: modulepath /usr/local/openldap/sbin moduleload back_hdb.la moduleload rwm.la database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /usr/local/openldap/var/data index objectClass eq index entryCSN,entryUUID eq overlay rwm Simple database: dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example o: example.com

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by ando＠sys-net.it 14 Apr '09

14 Apr '09

> I chatted with David about this on IRC. The situation is using > slapo-rwm on > top of back-relay, pointed at a local (back-bdb) database. He has an > ACL in > the relay database using a filter, e.g.: > access to filter=(foo=bar) by * read > > In slapo-rwm rwm_attr(), when an explicit list of attributes is > requested in a > search, any attributes that weren't requested are stripped from the > entry. > Thus, attribute foo disappears if it is not part of the attrs list, > and then > the entry cannot be retrieved by the client. > > However, if no attr list is specified then slapo-rwm passes the entire > entry > through unmolested, and the ACL works. This is because search ACLs assume they will see the whole entry regardless of what attributes were requested in the search operation. The "right" solution consists in making ACL evaluation functions fetch the attr they need from the database, rather than from the entry, as it might have already been massaged. 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#5856) adauth overlay contribution
by neil.dunbar＠hp.com 14 Apr '09

14 Apr '09

Howard, Fair comments - the package was basically wrapped up from an internal packa= ge used in HP (which indeed has internal processes to map ED accounts to th= eir equivalent AD DNs). The desire was to donate the package rather than se= e it live only in HP - at least someone might find a use for it. Clearly yo= u think that the friction of installation limits its utility - and that's a= perfectly fine observation. A lot of the "mapping" name stuff was legacy from when there was a lot more= functionality in the package, since it did NTLM authentication as well, to= a multitude of NT4 domain controllers. In that world, there really was a m= apping, but that's not true in the simplified world of Adauth. In light of the comments, it's probably better to drop the package in its e= ntirety until I have time to address the structural issues highlighted. Cheers, Neil

1 0

Re: (ITS#6057) "slapo-rwm interferes with content-sensitive ACLs"
by hyc＠symas.com 14 Apr '09

14 Apr '09

ando(a)sys-net.it wrote: > ----- admin(a)dmarkey.com wrote: > >> Full_Name: David Markey >> Version: 2.4.15 >> OS: Debian >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (86.47.26.12) >> >> >> When using a slapo-rwm in conjunction with filter based ACL like >> >> access to filter="memberOf=cn=staff,ou=groupofnames,dc=thunderbird" >> >> This wont work unless the client explicitly requests the memberOf >> attribute. >> >> The client in this case in thunderbird, which doesn't request the >> memberof >> attribute > > You should specify the context of your use of slapo-rwm. The limitation > might not be in the overlay itself, but in your design of the DSA that uses > slapo-rwm. Unless a more detailed description of the configuration > highlights a true software bug or design issue, I'm keen to considering > this a user error. I chatted with David about this on IRC. The situation is using slapo-rwm on top of back-relay, pointed at a local (back-bdb) database. He has an ACL in the relay database using a filter, e.g.: access to filter=(foo=bar) by * read In slapo-rwm rwm_attr(), when an explicit list of attributes is requested in a search, any attributes that weren't requested are stripped from the entry. Thus, attribute foo disappears if it is not part of the attrs list, and then the entry cannot be retrieved by the client. However, if no attr list is specified then slapo-rwm passes the entire entry through unmolested, and the ACL works. -- -- 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#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 14 Apr '09

14 Apr '09

--=-z3vwQM0YDtLESpiQMoYR Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-04-14 at 10:09 +0200, Pierangelo Masarati wrote: > ----- abartlet(a)samba.org wrote: >=20 > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > > Submission from: (NULL) (59.167.251.137) > >=20 > >=20 > > Active Directory always presents an attribute 'name' that is always > > equal to the > > relative distinguished name. AD allows only one RDN, but I don't mind > > if this > > can be multi-valued for the multi-RDN case. It is equal to the value > > of the RDN > > as presented in the RDN. > >=20 > > This is not simply the subtype 'CN -> name', but a new attribute > > unrelated to > > the existing definition of 'name'. > >=20 > > I don't care what name is assigned to 'name', as I can easily remap > > attributes. > >=20 > > It would be great if this could be constructed such that it may be > > declared to > > be unique for a particular one-level search (also an AD requirement, > > but not one > > Samba4 requires or enforces at this time). =20 >=20 > The only problem I see in defining such an attribute is that its > syntax should allow the value of any syntax, so it should probably be > octetString or something like that. =20 I think the AD document I reference explains that only some attributes can be an RDN, so it limits them to those with a unicode string representation I suppose.=20 There is another attribute that follows the 'type' of RDN btw (never seen it used, but it's in the docs).=20 > From the implementation point of view, what operations should it be > used for? If you only need it to be returned with searches, and to be > compared, then the implementation would be trivial (it could be > dynamically generated, much like entryDN, as far as I can tell). If > you need to search for it, namely use it in a filter, then it might be > better to store it in the database. This would require to handle add > and modrdn, forbid modify, and nothing else. Like entryDN, we need to be able to search on it, so it should probably be persistent. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-z3vwQM0YDtLESpiQMoYR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJ5En/z4A8Wyi0NrsRAr6BAJ9TfUOgXqi25ArjKIXGVWDacL770gCgql6i 64vwlQj1AfncVVS2bCJlH5g= =31Zg -----END PGP SIGNATURE----- --=-z3vwQM0YDtLESpiQMoYR--

1 0

Re: (ITS#6055) Samba4 need 'name' implementation like AD (RDN-Name)
by ando＠sys-net.it 14 Apr '09

14 Apr '09

----- abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: http://msdn.microsoft.com/en-us/library/cc223167(PROT.13).aspx > Submission from: (NULL) (59.167.251.137) > > > Active Directory always presents an attribute 'name' that is always > equal to the > relative distinguished name. AD allows only one RDN, but I don't mind > if this > can be multi-valued for the multi-RDN case. It is equal to the value > of the RDN > as presented in the RDN. > > This is not simply the subtype 'CN -> name', but a new attribute > unrelated to > the existing definition of 'name'. > > I don't care what name is assigned to 'name', as I can easily remap > attributes. > > It would be great if this could be constructed such that it may be > declared to > be unique for a particular one-level search (also an AD requirement, > but not one > Samba4 requires or enforces at this time). The only problem I see in defining such an attribute is that its syntax should allow the value of any syntax, so it should probably be octetString or something like that. From the implementation point of view, what operations should it be used for? If you only need it to be returned with searches, and to be compared, then the implementation would be trivial (it could be dynamically generated, much like entryDN, as far as I can tell). If you need to search for it, namely use it in a filter, then it might be better to store it in the database. This would require to handle add and modrdn, forbid modify, and nothing else. 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