openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 5:36 PM +0000 quanah(a)zimbra.com wrote: Additional notes: [09:07] <hyc> manage access gives you permission to use the Relax control on a modify request [09:07] <hyc> to write to an attribute that is otherwise not user-writable [09:07] <hyc> only a small set of operational attributes are manageable [09:08] <hyc> createtimestamp, modifytimestamp, creatorsname, modifiersname, entryUUID, entryTTL [09:09] <hyc> otherwise, the relax control is useless [09:09] <hyc> hm, the ppolicy opattrs are also manageable -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by michael＠stroeder.com 31 Jan '14

31 Jan '14

pierangelo.masarati(a)polimi.it wrote: > On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >> What does administrative access mean? > > It allows write when write is granted and the "relax" control is > present. In practice, those who have "manage" access can perform those > normally "prohibited" operations described in draft-zeilenga-ldap-relax. I wish this explanation would catch all cases. I vaguely remember that before the birth of draft-zeilenga-ldap-relax some (overlays?) misused the Manage DSA IT control for that purpose. Ciao, Michael.

1 0

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 5:11 PM +0000 michael(a)stroeder.com wrote: > quanah(a)OpenLDAP.org wrote: >> What does administrative access mean? > > I can't describe the full meaning, only a specific use case: > > In some deployments I grant certain admins the right to remove > 'pwdHistory' attribute from an entry. Since this is an operational > attribute one has to grant also manage privilege for letting the client > remove the attribute in case it sends the Relax Rules control along with > the modify request. > > (yes, web2ldap implements this particular use case ;-) > > Example: > > access to > attrs=pwdHistory > by group="cn=all-mighty admins,dc=example,dc=com" =zm > by * none > > AFAIK this also applies to altering other operational attributes by using > Relax Rules control. > > Maybe you can take this as a start for a more general text. Great example, thanks! --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by quanah＠zimbra.com 31 Jan '14

31 Jan '14

--On Friday, January 31, 2014 6:08 PM +0100 Pierangelo Masarati <pierangelo.masarati(a)polimi.it> wrote: > On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.39 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> The documentation in the Admin guide and the man pages for the "manage" >> ACL setting has virtual no documentation. The only definitive statement >> is a very vague: >> >> " thus manage grants all access including administrative access" >> >> What does administrative access mean? > > It allows write when write is granted and the "relax" control is present. > In practice, those who have "manage" access can perform those normally > "prohibited" operations described in draft-zeilenga-ldap-relax. Excellent, thank you very much. ;) --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7795) "manage" access right needs better description
by michael＠stroeder.com 31 Jan '14

31 Jan '14

quanah(a)OpenLDAP.org wrote: > What does administrative access mean? I can't describe the full meaning, only a specific use case: In some deployments I grant certain admins the right to remove 'pwdHistory' attribute from an entry. Since this is an operational attribute one has to grant also manage privilege for letting the client remove the attribute in case it sends the Relax Rules control along with the modify request. (yes, web2ldap implements this particular use case ;-) Example: access to attrs=pwdHistory by group="cn=all-mighty admins,dc=example,dc=com" =zm by * none AFAIK this also applies to altering other operational attributes by using Relax Rules control. Maybe you can take this as a start for a more general text. Ciao, Michael.

1 0

Re: (ITS#7795) "manage" access right needs better description
by pierangelo.masarati＠polimi.it 31 Jan '14

31 Jan '14

On 01/31/2014 05:49 PM, quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > The documentation in the Admin guide and the man pages for the "manage" ACL > setting has virtual no documentation. The only definitive statement is a very > vague: > > " thus manage grants all access including administrative access" > > What does administrative access mean? It allows write when write is granted and the "relax" control is present. In practice, those who have "manage" access can perform those normally "prohibited" operations described in draft-zeilenga-ldap-relax. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7795) "manage" access right needs better description
by quanah＠OpenLDAP.org 31 Jan '14

31 Jan '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) The documentation in the Admin guide and the man pages for the "manage" ACL setting has virtual no documentation. The only definitive statement is a very vague: " thus manage grants all access including administrative access" What does administrative access mean?

1 0

(ITS#7794) RFE: Versioned LMDB shared library
by jstanek＠redhat.com 29 Jan '14

29 Jan '14

Full_Name: Jan Stanìk Version: LMDB 0.9.11 OS: Fedora 20 URL: Submission from: (NULL) (209.132.186.34) I'm trying to package LMDB for Fedora as possible system-wide replacement for Oracle's BerkeleyDB. The main trouble is that in current state the LMDB builds an unversioned liblmdb.so. I would like to propose to start versioning of liblmdb.so, so it would be possible to include it into ditribution without the possibility of sudden ABI break.

1 0

(ITS#7793) mdb_cursor_put(,,,MDB_CURRENT) should ignore key
by h.b.furuseth＠usit.uio.no 28 Jan '14

28 Jan '14

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.11 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-140128.c Submission from: (NULL) (81.191.45.35) Submitted by: hallvard The doc for mdb_cursor_put:MDB_CURRENT says "The key parameter is ignored". However: - key==NULL gives EINVAL after a thinko in the assert cleanup. 5bda3565a9bfaa6cd54053faeafcc06da15bc00c moved assert(key) from mdb_cursor_set() to the wrong place in the one relevant caller. - A huge key.mv_size triggers mdb_page_spill(). - If data.mv_size==0, the record's key instead of data is modified (so you can modify e.g. key:"foo" to key:"bar"). I expect the test should be (mc->mc_flags & C_SUB). Changing that has a side effect on a non-MDB_CURRENT case: With a cmp function like strncasecmp, changing "KEY" to "key" currently works with if old datasize = new datasize = 0. After this it won't, as with non-empty data of the same size. Test program enclosed.

1 0

(ITS#7792) slapd problems - ldap_result: Can't contact LDAP server (-1) result.c:813
by warron.french＠aero.org 27 Jan '14

27 Jan '14

Full_Name: Warron French Version: 2.4.38 LTB Project OS: CentOS-6.5 URL: Submission from: (NULL) (130.221.145.5) LTB-Project.org or OpenLDAP.org developers, please help: I am running CentOS-6.5 (on all machines in my little lab) and attempting to setup an LDAP server for user-account authentication, which requires TLS. My CentOS-6.5 machines are all running kernel 2.6.32-431.3.1.el6.x86_64. Also, the version of OpenLDAP I am running based on a suggestion from a user is LTB-Project.org's OpenLDAP-2.4.38, because the version that came natively available with CentOS-6.5's repos was a very old 2.4.23. I am writing a document in order to successfully repeat the build/configuration steps from my lab and lessons learned into a production system. The following is where I am... I am still having problems with adding (via .ldif file) the following LDIF file contents of /tmp/LDAP-CONFIG-TLS.ldif: dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: TLSv1+RSA:\!EXP:\!MD5:\!NULL (<- not sure if that argument is valid for that CipherSuite selection either) I use the following ldapmodify command: ldapmodify -x -D "cn=admin,cn=config" -W -f /tmp/LDAP-CONFIG-TLS.ldif Because I have debugging turned up (to -d 32768), the results now look like: modifying entry "cn=config" 52e68423 connection_input: conn=1000 deferring operation: binding slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. ldap_result: Can't contact LDAP server (-1) I saw a thread on openldap.org on the following link, http://www.openldap.org/lists/openldap-bugs/201308/msg00066.html , that has the exact same error. I can see that Howard Chu from Symas fixed the problem for Symas, did LTB Project fix this problem? I cannot find any threads via websearch for this issue. My /var/log/openldap.log file does not show anything extra. In fact a tail of the log file doesn't even show any errors really. What do I need to do in order to get my LDAP running with TLS? Thank you for any help, I am losing my sanity.

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