11:13 p.m.
Hello,
I've just submitted a patch to help make the collect overlay
(attribute inheritance) a bit more useful (ITS#5659).
As part of my testing work for the above i once accidentally created a
postalAddress attribute with two values. When i tried to remove the
extra attribute value it failed, the error i got was something like
that there is no matching rule for postalAddress, which if there
really isn't then it's probably a reasonable thing for slapd to
complain about, as it wont be able to tell the individual values of
postalAddress apart.
So to put it in a nutshell, i'm willing to have a go implementing a
postalAddress matching rule, but i was wondering if anyone has any
thoughts where i might begin, and/or any pointers as to which file(s)
implement the matching rules.
Cheers
Brett
10:04 a.m.
--On Tuesday, August 26, 2008 4:13 PM +1000 "Brett @Google"
<brett.maxfield(a)gmail.com> wrote:
Hello,
I've just submitted a patch to help make the collect overlay
(attribute inheritance) a bit more useful (ITS#5659).
As part of my testing work for the above i once accidentally created a
postalAddress attribute with two values. When i tried to remove the
extra attribute value it failed, the error i got was something like
that there is no matching rule for postalAddress, which if there
really isn't then it's probably a reasonable thing for slapd to
complain about, as it wont be able to tell the individual values of
postalAddress apart.
So to put it in a nutshell, i'm willing to have a go implementing a
postalAddress matching rule, but i was wondering if anyone has any
thoughts where i might begin, and/or any pointers as to which file(s)
implement the matching rules.
Does the RFC proclaim a matching rule for postalAddress? Because if it
doesn't, there's no point in defining one. ;) If an attr doesn't have a
matching rule, you have to use a replace op rather than delete.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:11 a.m.
Brett,
Brett @Google wrote:
As part of my testing work for the above i once accidentally created a
postalAddress attribute with two values. When i tried to remove the
extra attribute value it failed, the error i got was something like
that there is no matching rule for postalAddress, which if there
really isn't then it's probably a reasonable thing for slapd to
complain about, as it wont be able to tell the individual values of
postalAddress apart.
So to put it in a nutshell, i'm willing to have a go implementing a
postalAddress matching rule, but i was wondering if anyone has any
thoughts where i might begin, and/or any pointers as to which file(s)
implement the matching rules.
I don't want to hold you back from implementing the EQUALITY matching
rule for PostalAdress syntax.
But you could also just delete the whole attribute and re-add the
value(s) needed. (That's how the delta-modification works in web2ldap if
the EQUALITY matching rule is not implemented.)
Ciao, Michael.
10:13 a.m.
Quanah Gibson-Mount wrote:
Does the RFC proclaim a matching rule for postalAddress? Because if it
doesn't, there's no point in defining one. ;) If an attr doesn't have a
matching rule, you have to use a replace op rather than delete.
Yes. And OpenLDAP even announces it in the subschema without
implementing it (see also ITS#5608). :-(
Ciao, Michael.
10:20 a.m.
--On Tuesday, August 26, 2008 7:13 PM +0200 Michael Ströder
<michael(a)stroeder.com> wrote:
Quanah Gibson-Mount wrote:
>
> Does the RFC proclaim a matching rule for postalAddress? Because if it
> doesn't, there's no point in defining one. ;) If an attr doesn't have a
> matching rule, you have to use a replace op rather than delete.
Yes. And OpenLDAP even announces it in the subschema without implementing
it (see also ITS#5608). :-(
Ah, well, then I certainly encourage Brett to implement it. ;)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:22 a.m.
On Aug 26, 2008, at 10:13 AM, Michael Ströder wrote:
Yes. And OpenLDAP even announces it in the subschema without
implementing it (see also ITS#5608). :-(
An ITS which should be closed.
An implementation can either publish the attribute description as
specified (possibly with some additional names, extensions) or not.
The description is otherwise immutable (per X.501).
Note that publication of a schema description only indicates that the
implementation is aware of the description. It does not necessarily
mean that the server implements any particular functionality (other
than the ability to publish schema descriptions).
-- Kurt
10:45 a.m.
Kurt Zeilenga wrote:
An implementation can either publish the attribute description as
specified (possibly with some additional names, extensions) or not. The
description is otherwise immutable (per X.501).
Note that publication of a schema description only indicates that the
implementation is aware of the description. It does not necessarily
mean that the server implements any particular functionality (other than
the ability to publish schema descriptions).
...still we disagree on that. If consequently applied this paradigm
would render the subschema subentry completely unusable for the client.
IMO the subschema subentry SHOULD reflect what is effective on the
server's side. Otherwise a client cannot find out what to do by looking
at the schema.
I've somewhat solved my problem by also looking whether the referenced
EQUALITY matching rule (here caseIgnoreListMatch) is listed in subschema
subentry's attribute 'matchingRules'. But taking your wording literally
even this wouldn't be guaranteed.
Ciao, Michael.
11:43 a.m.
On Aug 26, 2008, at 10:45 AM, Michael Ströder wrote:
Kurt Zeilenga wrote:
> An implementation can either publish the attribute description as
> specified (possibly with some additional names, extensions) or
> not. The description is otherwise immutable (per X.501).
> Note that publication of a schema description only indicates that
> the implementation is aware of the description. It does not
> necessarily mean that the server implements any particular
> functionality (other than the ability to publish schema
> descriptions).
...still we disagree on that. If consequently applied this paradigm
would render the subschema subentry completely unusable for the
client. IMO the subschema subentry SHOULD reflect what is effective
on the server's side. Otherwise a client cannot find out what to do
by looking at the schema.
I think you simply fail to realize that the subschema publication
mechanism has limitations to its usefulness. As specified, it's
simply not terribly usable as an implementation-supported-feature
discovery mechanism. (When LDAP was being revised, I did suggest how
it could become more useful, those suggestions were not supported by
the consensus of the WG. Oh well.)
What you suggestion, I think, is quite problematic. Saying an
attribute has no equality rule is not the same as saying a particular
implementation doesn't support a particular rule. If a server where
to say "this attribute has no equality rule", then others (clients or
servers reading this) might not apply the equality rule even though
they have implemented it. That might lead to very odd behavior.
I've somewhat solved my problem by also looking whether the
referenced EQUALITY matching rule (here caseIgnoreListMatch) is
listed in subschema subentry's attribute 'matchingRules'. But taking
your wording literally even this wouldn't be guaranteed.
This seems no worse than taking a statement that an attribute has no
equality rule to mean that attribute has an equality rule that is not
implemented.
-- Kurt
3:36 p.m.
Kurt Zeilenga wrote:
I think you simply fail to realize that the subschema publication
mechanism has limitations to its usefulness. As specified, it's simply
not terribly usable as an implementation-supported-feature discovery
mechanism. (When LDAP was being revised, I did suggest how it could
become more useful, those suggestions were not supported by the
consensus of the WG. Oh well.)
Could you please point me to some related postings in the ietf-ldapbis
mailing list archive?
What you suggestion, I think, is quite problematic. Saying an
attribute
has no equality rule is not the same as saying a particular
implementation doesn't support a particular rule. If a server where to
say "this attribute has no equality rule", then others (clients or
servers reading this) might not apply the equality rule even though they
have implemented it. That might lead to very odd behavior.
Your argument might be ok in this particular case and, as I said, I have
a work-around for that particular case. But in general it's debatable
whether the subschema is 1. advice to the client to do the right thing
or 2. to indicate to the client what the server does. I've seen many
interpretations in both directions - in discussions and in implementations.
Ciao, Michael.
5:16 p.m.
I don't want to hold you back from implementing the EQUALITY
matching rule
for PostalAdress syntax.
But you could also just delete the whole attribute and re-add the value(s)
needed. (That's how the delta-modification works in web2ldap if the EQUALITY
matching rule is not implemented.)
Yes that's what i did to fix my test data, but specifically this
change was made indirectly by the collect.c overlay, not manually by
me, which populates attributes from a parent or template object
through to all the children of that object. I want to use the collect
overlay to make child objects have the same postalAddress (amoung
other attributes) of some parent or template object, such as some
superior ou entry that is component of the user's dn.
This issue arises as to what happens to when you try to edit
postalAddress in a child object which has collected an attribute from
some parent, what is presently happening is that the parent gets
another duplicate attribute value on the inherited attribute. In other
words it allows the change, but it cannot tell that the new attribute
value is the same as the old attribute value.
While this is probably a bug that needs fixing, i'm considering the
best option for a workaround.
While this probably can be simply fixed by disallowing writes on
attributes of child object which are collect-ed from a parent, my
thought was that if there was an equality matching rule and it were
implemented, the update would fail or silently ignore the update (as
ldap would normally) because the attribute already has that value, and
it would be a tidier / more correct solution.
To paraphrase, i'd prefer to leave the decision as to whether the
attribute MAY be written, to the access control system, and just work
on the fact wether the attribute should be written (ie. it already has
that value, so request should be silently ignored or errored, i favour
the former) which is more correct IMHO, just disabling writes is
ignoring the problem (although that also might be a nice feature).
Cheers
Brett
2:03 a.m.
Brett @Google wrote:
> I don't want to hold you back from implementing the EQUALITY
matching rule
> for PostalAdress syntax.
>
> But you could also just delete the whole attribute and re-add the value(s)
> needed. (That's how the delta-modification works in web2ldap if the EQUALITY
> matching rule is not implemented.)
Yes that's what i did to fix my test data, but specifically this
change was made indirectly by the collect.c overlay, not manually by
me, which populates attributes from a parent or template object
through to all the children of that object. I want to use the collect
overlay to make child objects have the same postalAddress (amoung
other attributes) of some parent or template object, such as some
superior ou entry that is component of the user's dn.
This issue arises as to what happens to when you try to edit
postalAddress in a child object which has collected an attribute from
some parent, what is presently happening is that the parent gets
another duplicate attribute value on the inherited attribute. In other
words it allows the change, but it cannot tell that the new attribute
value is the same as the old attribute value.
slapo-collect should intercept the write request and forbid the write
access if the attribute type is declared with COLLECTIVE.
While this probably can be simply fixed by disallowing writes on
attributes of child object which are collect-ed from a parent, my
thought was that if there was an equality matching rule and it were
implemented, the update would fail or silently ignore the update (as
ldap would normally) because the attribute already has that value, and
it would be a tidier / more correct solution.
Again: I'd appreciate if you would implement caseIgnoreListMatch but
this particular issue should be fixed in a more general way.
Ciao, Michael.
10:33 a.m.
On Sat, Aug 30, 2008 at 7:03 PM, Michael Ströder <michael(a)stroeder.com> wrote:
slapo-collect should intercept the write request and forbid the write
access
if the attribute type is declared with COLLECTIVE.
Yep. That sounds reasonable, but i presume it should either return an
unwilling to perform, or silently ignore it. The latter case would be
better if dumping out a ldap database (as it would be dumped as a
"real" attribute) and then wanting to import that same data back ?
Again: I'd appreciate if you would implement caseIgnoreListMatch
but this
particular issue should be fixed in a more general way.
I was starting to investigate this, but it looks like ando has already
done it :)
Cheers
Brett
4:31 a.m.
Brett @Google wrote:
On Sat, Aug 30, 2008 at 7:03 PM, Michael Ströder
<michael(a)stroeder.com> wrote:
> slapo-collect should intercept the write request and forbid the write access
> if the attribute type is declared with COLLECTIVE.
Yep. That sounds reasonable, but i presume it should either return an
unwilling to perform, or silently ignore it.
I'd prefer to not silently ignore it since returning unwillingToPerform
clearly indicates that a client is misbehaving which needs correction.
The latter case would be
better if dumping out a ldap database (as it would be dumped as a
"real" attribute) and then wanting to import that same data back ?
slapadd is a completely different use-case anyway because operational
attributes are also imported.
Ciao, Michael.
6:14 a.m.
On Sun, Aug 31, 2008 at 9:31 PM, Michael Ströder <michael(a)stroeder.com> wrote:
>> slapo-collect should intercept the write request and forbid
the write access
>> if the attribute type is declared with COLLECTIVE.
>
> Yep. That sounds reasonable, but i presume it should either return an
> unwilling to perform, or silently ignore it.
I'd prefer to not silently ignore it since returning unwillingToPerform
clearly indicates that a client is misbehaving which needs correction.
OK, i've implemented collect_modify() which returns unwillingToPerform for any
modify operation which contains an attribute which is a collect
attribute, leaving
alone non-collectinfo objects including the parent object
the collect attributes are not dumped by slapcat, so no changes there
Cheers
Brett
5387
days inactive
5397
days old
13 comments
4 participants
participants (4)
-
Brett ＠Google -
Kurt Zeilenga -
Michael Ströder -
Quanah Gibson-Mount