openldap-bugs January 2015

openldap-bugs@openldap.org

22 participants
114 discussions

Re: (ITS#8025) OpenLDAP authorisation on a client causes policykit GUI features to fail
by hyc＠symas.com 16 Jan '15

16 Jan '15

mez(a)debian.org wrote: > Full_Name: Martin Meredith > Version: 2.4.31 > OS: Xubuntu 14.04 > URL: > Submission from: (NULL) (81.174.171.8) > > > when combining libmap-ldap and policykit within ubuntu 14.04, this causes the > GUI portions of PolicyKit to fail. As a side effect, this causes the lockscreen > within Xubuntu 14.04 to be bypassable by a VT switch. > > I'm unsure as to what information you need to help diagnose this issue, but I > can provide any info as required. > > PolicyKit bug:- https://bugs.freedesktop.org/show_bug.cgi?id=88492 Sounds like your issue is with pam_ldap, which is not OpenLDAP software. As such, there is no code we own here that we can investigate for you. I note that PADL, the original authors of pam_ldap, stopped supporting it many many years ago. For several years they were referring support customers to Symas, but we at Symas also deprecated pam_ldap many years ago in favor of nssov. > Ubuntu Bug: https://bugs.launchpad.net/policykit-1/+bug/1410195 There's nothing here that indicates any connection to OpenLDAP either. -- -- 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

(ITS#8025) OpenLDAP authorisation on a client causes policykit GUI features to fail
by mez＠debian.org 16 Jan '15

16 Jan '15

Full_Name: Martin Meredith Version: 2.4.31 OS: Xubuntu 14.04 URL: Submission from: (NULL) (81.174.171.8) when combining libmap-ldap and policykit within ubuntu 14.04, this causes the GUI portions of PolicyKit to fail. As a side effect, this causes the lockscreen within Xubuntu 14.04 to be bypassable by a VT switch. I'm unsure as to what information you need to help diagnose this issue, but I can provide any info as required. PolicyKit bug:- https://bugs.freedesktop.org/show_bug.cgi?id=88492 Ubuntu Bug: https://bugs.launchpad.net/policykit-1/+bug/1410195

1 0

Re: (ITS#8024) Password Policy Logging Enhancement
by michael＠stroeder.com 14 Jan '15

14 Jan '15

mwarren(a)symas.com wrote: > We would like make a new feature request for enhanced logging within the > Password Policy Module. A customer has a need for logging of automated password > lockouts which occur after a certain number of failed binds within a given time > window. Pertinent info would include the DN of the locked out user as well as > the source IP of the failed attempt(s). When running a consumer with slapo-accesslog (yes, not for delta-syncrepl) slapo-ppolicy's modifications are written to the accesslog-DB. I use it in a highly secure environment for seeing logins (slapo-lastbind) and login failures (but no failure lockout). Having just a syslog entry in this case would probably better regarding performance though. Maybe even a info message along with the BIND RESULT message would do. Ciao, Michael.

1 0

(ITS#8024) Password Policy Logging Enhancement
by mwarren＠symas.com 14 Jan '15

14 Jan '15

Full_Name: Mark Warren Version: 2.4.x OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.35.133.119) Greetings, We would like make a new feature request for enhanced logging within the Password Policy Module. A customer has a need for logging of automated password lockouts which occur after a certain number of failed binds within a given time window. Pertinent info would include the DN of the locked out user as well as the source IP of the failed attempt(s). Best Regards, Mark

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by leo＠yuriev.ru 14 Jan '15

14 Jan '15

2015-01-14 8:49 GMT+03:00 Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no>: > On 13/01/15 19:23, Hallvard Breien Furuseth wrote: >> >> Yes, that didn't come out right. I don't mind inserting the >> volatile, but I don't know that it helps either. As far as I >> understand if it was broken without volatile, then it's still >> broken with it - just hopefully less likely to break. And LMDB >> couldn't be releaseed with your original unportable sync code >> along with the volatile. > > > Sorry, nevermind. Of course when the writer does sync well enough, > volatile + the txn_renew loop will have to do for a sync primitive in > the reader. > I suppose this requires that sync in the writer thread > will shake other threads as well, it won't be private to the writer. In general this is wrong, more precisely depend on 'volatile' on shared variables and usage of barriers/fences by the readers. Sync-ops due lock/release a mutex by writer issue a memory-barrier for its own thread. With this compiler must update all modified variables, which shaded in the CPU registers. Next a hardware write-barrier (aka release) in the mutex-release code enforce all changes to be visible for other threads (e.g. flush the cache). But 'be visible' here mean 'publish' and other threads can access these changes, but if want this. In general, to see changes made by the writer, all other threads should issue a read-barrier (aka acquire). On most arches such barrier just inform compiler that memory was changed and variables which cached in the registers must be reloaded. But in some cases (like Itanium) this barrier will be taken in account for instruction scheduling. For 'volatile' compiler should generate barriers each time on read or write such variables. More general, memory-barriers are very important to HPC, distributed computing and for super-computers. For example read-barriers may pull changes from internode-bus or other nodes, and write-barriers - publish the local changes. So, the one way to avoid a race bugs - thinking in terms of publish/pull changes.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 14 Jan '15

14 Jan '15

--On Wednesday, January 14, 2015 11:00 AM +0000 freebsd(a)jonathanprice.org wrote: > Hi, > > I tried 2.4.39 under FreeBSD and still had the same issue. > > I have also tried the packages for both CentOS 7 and Debian Wheezy, but > unfortunately neither of them include the SHA2 overlay by default. > > Finally, I tried installing zimbra-core and zimbra-ldap under CentOS. > When I used this installation, it worked successfully. > > I ran slapd -V on the zimbra installation, and it's 2.4.39. However, > based on it still not working on 2.4.39 on FreeBSD it appears to have > narrowed it down to two reasons: - An issue with the packaging under > FreeBSD > - The functionality is specific to Zimbra > > The next step in the process to narrow this down is to do a manual > compilation on CentOS, including the SHA2 overlay. If this works, then it > would confirm it to be a FreeBSD issue, and if it doesn't work that would > strongly suggest that Zimbra has modified something. You could simply grab the LTB project builds. I'm pretty sure they build out the contrib modules. In any case, I already noted that Zimbra doesn't patch anything in OpenLDAP that would affect this area. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 14 Jan '15

14 Jan '15

Hi,=0A=0AI tried 2.4.39 under FreeBSD and still had the same issue.=0A=0A= I have also tried the packages for both CentOS 7 and Debian Wheezy, but u= nfortunately neither of them include the SHA2 overlay by default.=0A=0AFi= nally, I tried installing zimbra-core and zimbra-ldap under CentOS. When = I used this installation, it worked successfully.=0A=0AI ran slapd -V on = the zimbra installation, and it's 2.4.39. However, based on it still not = working on 2.4.39 on FreeBSD it appears to have narrowed it down to two r= easons:=0A- An issue with the packaging under FreeBSD=0A- The functionali= ty is specific to Zimbra=0A=0AThe next step in the process to narrow this= down is to do a manual compilation on CentOS, including the SHA2 overlay= . If this works, then it would confirm it to be a FreeBSD issue, and if i= t doesn't work that would strongly suggest that Zimbra has modified somet= hing.=0A=0AThanks for the assistance so far,=0A=0A-Jonathan=0A=0AJanuary = 13 2015 8:00 PM, "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: =0A> --= On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price=0A> <freebsd@jo= nathanprice.org> wrote:=0A> =0A>> I do apologise for the confusion, I'll = try to clarify below:=0A>> =0A>> Here is the command you ran successfully= :=0A>> /opt/zimbra/openldap/sbin/slappasswd -h=0A>> '{SSHA512}' -o module= -path=3D/opt/zimbra/openldap/sbin/openldap -o=0A>> module-load=3Dpw-sha2 = -s test=0A>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5= We5HNkXxFfy5=0A>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9=0A>> =0A>> Here is an= example of me running just a plain SHA512=0A>> slappasswd -h '{SHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2=0A>> {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvI= h/1nsUN=0A>> zLDBMxfqa2Ob1f1ACio/w=3D=3D=0A>> =0A>> And here is an exampl= e of me running a salted SHA512 (SSHA512)=0A>> slappasswd -h '{SSHA512}' = -o module-path=3D/usr/local/libexec/openldap -o=0A>> module-load=3Dpw-sha= 2 -s test=0A>> Password verification failed.=0A>> =0A>> I hope this helps= to clarify.=0A> =0A> Yes, thank you. So I'm using 2.4.39. There were som= e minor changes to=0A> slapd-sha2 in 2.4.40. I will see if I can reproduc= e the issue with current=0A> RE24.=0A> =0A> --Quanah=0A> =0A> --=0A> =0A>= Quanah Gibson-Mount=0A> Platform Architect=0A> Zimbra, Inc. =0A> _______= ________________________=0A> =0A> Zimbra :: the leader in open source mes= saging and collaboration

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 13 Jan '15

13 Jan '15

On 13/01/15 19:23, Hallvard Breien Furuseth wrote: > Yes, that didn't come out right. I don't mind inserting the > volatile, but I don't know that it helps either. As far as I > understand if it was broken without volatile, then it's still > broken with it - just hopefully less likely to break. And LMDB > couldn't be releaseed with your original unportable sync code > along with the volatile. Sorry, nevermind. Of course when the writer does sync well enough, volatile + the txn_renew loop will have to do for a sync primitive in the reader. I suppose this requires that sync in the writer thread will shake other threads as well, it won't be private to the writer. -- Hallvard

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by quanah＠zimbra.com 13 Jan '15

13 Jan '15

--On Tuesday, January 13, 2015 7:24 PM +0000 Jonathan Price <freebsd(a)jonathanprice.org> wrote: > I do apologise for the confusion, I'll try to clarify below: > > Here is the command you ran successfully: > /opt/zimbra/openldap/sbin/slappasswd -h > '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o > module-load=pw-sha2 -s test > {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 > Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 > > Here is an example of me running just a plain SHA512 > slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 > {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUN > zLDBMxfqa2Ob1f1ACio/w== > > And here is an example of me running a salted SHA512 (SSHA512) > slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o > module-load=pw-sha2 -s test > Password verification failed. > > I hope this helps to clarify. Yes, thank you. So I'm using 2.4.39. There were some minor changes to slapd-sha2 in 2.4.40. I will see if I can reproduce the issue with current RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 13 Jan '15

13 Jan '15

I do apologise for the confusion, I'll try to clarify below: Here is the command you ran successfully: /opt/zimbra/openldap/sbin/slappasswd -h '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 Here is an example of me running just a plain SHA512 slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== And here is an example of me running a salted SHA512 (SSHA512) slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test Password verification failed. I hope this helps to clarify. On 2015-01-13 19:14, Quanah Gibson-Mount wrote: > --On Tuesday, January 13, 2015 7:11 PM +0000 Jonathan Price > <freebsd(a)jonathanprice.org> wrote: > >> Hi, >> >> From the original email: >> However, if I replace {SHA512} with {SSHA512} it produces the following >> output: >> Password verification failed. > > You also were not clear *where* you did this replacement. It is > certainly not valid to do this replacement on the generated hash, as the > generated has was non-salted, and just adding another S in there will > not magically make it salted. It is valid to do this replacement in the > slappasswd line when generating a hash, as per my example, so that a > salted hash is generated. > > --Quanah > > >> It's interesting to see that it does work under certain conditions then. >> It appears that your OpenLDAP installation is part of a Zimbra >> installation. Does Zimbra make any modifications to OpenLDAP, or is it >> just built on top of it? >> >> Either way, I think I'm going to try it on Debian, just to rule out it >> being a FreeBSD issue, which it quite well could be at this point. >> >> On 2015-01-13 19:01, Quanah Gibson-Mount wrote: >>> --On Tuesday, January 13, 2015 6:52 PM +0000 freebsd(a)jonathanprice.org >>> wrote: >>> >>>> Full_Name: Jonathan Price >>>> Version: 2.4.40 >>>> OS: FreeBSD 10.1 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (80.47.105.54) >>>> >>>> >>>> I have compiled version 2.4.40 with the SHA2 module enabled. >>>> >>>> I then run the slappasswd with the following arguments: >>>> slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o >>>> module-load=pw-sha2 >>> >>> You requested a non salted hash -> SHA512 >>> >>> Did you try requesting a salted hash? -> SSHA512 >>> >>> Works fine for me, and I've been using it in production for quite some >>> time. >>> >>> [zimbra@zre-ldap003 ~]$ /opt/zimbra/openldap/sbin/slappasswd -h >>> '{SSHA512}' -o module-path=/opt/zimbra/openldap/sbin/openldap -o >>> module-load=pw-sha2 -s test >>> {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5 >>> Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 >>> >>> >>> >>> --Quanah >>> >>> -- >>> >>> Quanah Gibson-Mount >>> Platform Architect >>> Zimbra, Inc. >>> -------------------- >>> Zimbra :: the leader in open source messaging and collaboration > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2015