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 …
[View More]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
[View Less]
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 …
[View More]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 |
-----------------------------------------------------------------------
[View Less]
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
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 …
[View More]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
[View Less]
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
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 …
[View More]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 |
-----------------------------------------------------------------------
[View Less]
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 …
[View More]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.
[View Less]
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.
…
[View More]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.
[View Less]
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 …
[View More]SSL negotiation debug lines from "slapd -d -1".
[View Less]
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 …
[View More]SSL negotiation debug lines from "slapd -d -1".
[View Less]