openldap-bugs June 2008

openldap-bugs@openldap.org

46 participants
176 discussions

(ITS#5564) Use largest contextCSN to determine staleness?
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Scenario: A syncrepl consumer replicates a backend DB where it has at least one entry that is up to date when it starts, but there are newer entries on the producer. The oldest contextCSN presented by the consumer is older than all entryCSN values in the replicated backend on the producer.. When syncprov_findcsn() is called with the FIND_CSN tag it will not find any entries whose entryCSN is <= the oldest csn presented by the consumer, and the cookie set will be determined as stale. Which again means that no present UUIDs will be sent to the consumer. The producer will, during the search that follows, skip sending entries whose entryCSN values are older or equal to a contextCSN with the same sid presented by the client. I.e the consumer will neither get these entries in a present UUID set nor as updated entries, and will therefore incorrectly remove them from its database. A fix that seems to solve this is that syncprov_findbase(FIND_CSN) should search for entries whose entryCSN value is less than the largest contextCSN presented by the client. All the test scripts succeed if I try this, but I'm not convinced that this is the correct fix. Would it not be more correct to ignore the entire CSN set presented by the consumer when it has been determined as stale? Hm, if the oldest contextCSN is from a server that is seldom updated this alternate fix could mean that a full reload would be performed every time the client starts with an outdated contextCSN set. Would the best fix be to do both, i.e search for entryCSN <= the largest csn presented by the client, and also ignore the csn set when it has been determined as stale? Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Mon, Jun 16, 2008 at 02:45:43PM +0200, Hallvard B Furuseth wrote: > If non-anonymous access is needed, the slapd.access(5) manpage needs an > update too. (Or instead, to avoid duplicating text.) Currently it just > says: > > Auth (=x) privileges are also required on the authzTo attribute > of the authorizing identity and/or on the authzFrom attribute of > the authorized identity. > > but it doesn't mention to who needs that auth access. It is the authenticated ID that needs access in both cases. On further thought I think it is correct that the access is checked without reference to whether that ID has access to entry and parent entries, as (particularly in the case of authzFrom) the authenticated ID may not have any direct access to the entry whose ID it is about to assume. Thus, if principal A has authenticated and wishes to perform an operation using principal B's authorisation, the access required is: A needs auth access to authzTo in its own entry if that attribute is involved in giving A permission to act for B. A needs auth access to authzFrom in B's entry if that attribute is involved in giving A permission to act for B. The rules are the same whether using a SASL authorization identity or using a ProxyAuth control on an LDAP operation. Thus I think my original report was wrong. This is a documentation issue, not a bug. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5561) SEGV using TLS/SASL
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

Please post your ldap.conf and slapd.conf, minus any passwords. > The pastebin URL contains the post SSL negotiation debug > lines from "slapd -d -1". No need to pastebin data as short as that. -- Hallvard

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by h.b.furuseth＠usit.uio.no 16 Jun '08

16 Jun '08

andrew.findlay(a)skills-1st.co.uk writes: > You are right: if I just grant 'auth' access to 'authzTo' the proxy > authorisation succeeds. The philisophy makes sense so I will try to > come up with a suitable patch to the Admin Guide describing how to use > it. At the moment the only note about this is in the ACL Examples > (7.2.5 at present) which says that authentication/authorization > is always done anonymously - obviously not entirely true. If non-anonymous access is needed, the slapd.access(5) manpage needs an update too. (Or instead, to avoid duplicating text.) Currently it just says: Auth (=x) privileges are also required on the authzTo attribute of the authorizing identity and/or on the authzFrom attribute of the authorized identity. but it doesn't mention to who needs that auth access. -- Hallvard

1 0

(ITS#5563) Seg. fault if URL used in ServerID without any listener
by rein＠OpenLDAP.org 16 Jun '08

16 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Slapd will seg. fault if the URL form of ServerID is used without any active listeners. I stumbled upon this by adding "-d ?" to my regular command line. I.e not exactly a critical bug.. I'll commit a trivial fix shortly. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5555) authzTo ACL check for wrong principal
by andrew.findlay＠skills-1st.co.uk 16 Jun '08

16 Jun '08

On Sat, Jun 14, 2008 at 03:59:37PM +0200, Pierangelo Masarati wrote: > AFAIK, access to that attribute is checked using AUTH rather than read. > The idea is that ACLs should allow to fine-grain control who is > allowed to exploit the authorization feature while giving up as little > as possible (e.g. AUTH instead of READ). You are right: if I just grant 'auth' access to 'authzTo' the proxy authorisation succeeds. The philisophy makes sense so I will try to come up with a suitable patch to the Admin Guide describing how to use it. At the moment the only note about this is in the ACL Examples (7.2.5 at present) which says that authentication/authorization is always done anonymously - obviously not entirely true. I am still a bit worried about the logic of the access test, as in my enviroment I just had to grant the principal auth access to their own authzTo attribute to make proxy authorization work: the principal does not even have 'disclose' access to their own entry or the parent entry. Normally I would expect to need some level of access to everything in the DN before I could make use of an attribute in an entry. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5554) slapd.conf man page missing TLSCipherSuite
by ghenry＠suretecsystems.com 16 Jun '08

16 Jun '08

hyc(a)symas.com wrote: > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> http://www.openldap.org/software/man.cgi?query=slapd.conf&sektion=5&apropos… >> missing TLSCipherSuite >> >> >> > No. The Admin Guide is missing the note about GnuTLS under the TLSCipherSuite > description. The note is present in slapd.conf(5). > Where would you like this to be mentioned in the Admin Guide, the only reference to TLSCipherSuite in the guide is in the TLS section, not in the config section. For now I've added: To obtain the list of ciphers in GNUtls use: > gnutls-cli -l in tls.sdf under the openssl cli part. -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

Re: (ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Duplicate. Please close. ----- Original Message ----- From: openldap-its(a)OpenLDAP.org To: "lea anthony" <lea.anthony(a)meirion-dwyfor.ac.uk> Sent: Monday, June 16, 2008 10:00:49 AM (GMT) Europe/London Subject: Re: (ITS#5562) SEGV using TLS/SASL *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5562. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5562) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5562) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=5562 Please remember to retain your issue tracking number (ITS#5562) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#5562) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

Full_Name: Lea Anthony Version: 2.3.40 OS: Arch Linux URL: http://pastebin.com/f6b680f22 Submission from: (NULL) (194.82.229.100) I have TLS setup as follows: TLSCertificateFile /etc/openldap/certs/cert.pem TLSCertificateKeyFile /etc/openldap/certs/key.pem TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3 The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind fine. However, doing "ldapsearch -ZZ" will cause a segfault on the server. The pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".

1 0

(ITS#5561) SEGV using TLS/SASL
by lea.anthony＠meirion-dwyfor.ac.uk 16 Jun '08

16 Jun '08

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2008