openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

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

14 Apr '09

----- 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. 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#6057) "slapo-rwm interferes with content-sensitive ACLs"
by admin＠dmarkey.com 13 Apr '09

13 Apr '09

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

1 0

(ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 13 Apr '09

13 Apr '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.167.251.137) Samba4's provision and 'make test' seems to create some internal situation in OpenLDAP slapd where it will not accept any more connections over ldapi:/// This is best seen by building Samba4, and running TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test The slapd does not crash, but simply stops accepting new connections. Samba4 currently then crashes due to some other bug (the LDAP backend not responding is clearly untested code in Samba4). It isn't a Samba4 client bug, as ldapsearch also fails to respond. This seems very, very similar to ITS#5261

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