Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it
michael.heep(a)o2.com wrote:
> the following valsort + dynlist combination causes slapd to utilize 100% cpu
> time when issueing searches against parts of the DIT containing attribute-value
> pairs "created" by dynlist:
>
> overlay dynlist
> dynlist-attrset extensibleObject memberURL uniqueMember
>
> overlay valsort
> valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend
>
> When run independent both overlays work flawlessly.
>
To be honest, I don't quite see the point in keeping sorted a set of
values that by definition is dynamically built. There seems to be
contradiction between the two overlays that prevents them from being
used together anyway. If your intention is to partition a tree so that
the intersection of data subjected to valsort and data subjected to
dynlist is empty, then I guess the solution is to use the <attri> and
<baseDN> parameters of valsort to exclude those entries that are
subjected to dynlist. If this is not enough, you could ask for an
enhancement that turns the <attr> <baseDN> into a more general
specification that allows increased granularity; for example, an attr
and a filter, which incidentally could be specified by means of an URL
so that base, attribute list, scope and filter can be present.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
Re: (ITS#4762) Bugs in meta backend
by Kurt＠OpenLDAP.org
As there is no major security issue here, this report is now public.
At 03:01 AM 11/24/2006, jerome.thevenet(a)aviation-civile.gouv.fr wrote:
>Full_Name:
>Version: 2.3.27
>OS: ubuntu
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (213.41.243.192)
>
>
>In Database meta:
>When we define several servers (uri: ldap//....),
>onerr CONTINUE
>
>If all servers are ok, the research is ok.
>But if one of them is off, the result of a research is error 52 even if the
>others send good result.
>
>Thanks
16 years, 6 months
RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de
>
> Fixed (differently) in HEAD/re23; please test. Thanks for
> reporting. p.
>
Just looked at your changes, of course it makes sense to put this in a
common function.
I will test over the weekend
Gerald
>
>
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
>
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> http://www.sys-net.it
> ------------------------------------------
> Office: +39.02.23998309
> Mobile: +39.333.4963172
> Email: pierangelo.masarati(a)sys-net.it
> ------------------------------------------
>
>
>
> ** Virus checked by BB-5000 Mailfilter **
> !DSPAM:4566ce0e132554386119908!
>
** Virus checked by BB-5000 Mailfilter **
16 years, 6 months
Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it
richter(a)ecos.de wrote:
Fixed (differently) in HEAD/re23; please test. Thanks for reporting. p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
(ITS#4761) error in "group" authorization parsing
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD,re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.28.220.33)
Submitted by: ando
When an authorization rule using groups, like "group:<dn>" is used, the default
member attribute "member" is erroneously set to an empy berval, resulting in an
invalid filter being used for the internal lookup to check for membership.
A workaround consists in avoiding defaults: "group/<oc>/<at>:<dn>".
"group/<oc>:<dn>" appears to work as intended, i.e. in this case the default
attribute is correctly used. A fix is coming.
p.
16 years, 6 months
Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it
Gerald Richter wrote:
>> I'm not sure I understand the issue you describe. In fact,
>> groups appear to be cached on a per-operation basis, and user
>> membership is evaluated using the authorized identity (B in
>> your case), so the behavior should be correct. I've made a
>> simple check using re23 and things appear to work as
>> expected: I log in as a user (A) that is not in a group and
>> authorize as a user (B) that is in that group. I previously
>> configured slapd so that only members of that group are
>> allowed to read an attribute in the whole db (say "cn").
>> Things work as expected: if I login as user A I can't see
>> "cn", but if I either log in as user B, or login as user A
>> and proxyAuthz as B I can read the "cn". Can you provide a
>> simple example (slapd.conf, db.ldif and sequence of
>> operations, e.g. in a shell script) that causes the issue you see?
>>
>>
>
> I think the point is that the group must be evaluated already in the search
> for the AuthzTo attribute.
>
> So my User A has the AuthzTo attribute set to User B and I have the
> following access control:
>
>
> access to *
> by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test"
> write
> by * break
>
> ...
>
>
> access to * attrs=authzTo
> by self read
> by * break
>
> ...
>
> User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when
> I log in as user A and proxyAuth to Openldap will evaluate the group
> membership for A and cache it, during the search for the ACL to authzTo. A
> is not member.
>
> Now when the actual search operation takes places, openldap will used the
> cached result (which was "is not member"), which is wrong because the user
> has changed since the group membership was cached.
>
> I hope this makes the problem more clear (I have a test environment here,
> but it is very complex and easy transferable)
>
OK, I see. In my test ACLs for authzTo didn't make use of groups. It
makes sense to clear out identity related cached stuff when the identity
changes. What I'm looking for is a __simple__ test that exploits the
feature. This would allow to clearly spot the issue in the first place,
and prepare a regression test. I'll do some more testing.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de
> I'm not sure I understand the issue you describe. In fact,
> groups appear to be cached on a per-operation basis, and user
> membership is evaluated using the authorized identity (B in
> your case), so the behavior should be correct. I've made a
> simple check using re23 and things appear to work as
> expected: I log in as a user (A) that is not in a group and
> authorize as a user (B) that is in that group. I previously
> configured slapd so that only members of that group are
> allowed to read an attribute in the whole db (say "cn").
> Things work as expected: if I login as user A I can't see
> "cn", but if I either log in as user B, or login as user A
> and proxyAuthz as B I can read the "cn". Can you provide a
> simple example (slapd.conf, db.ldif and sequence of
> operations, e.g. in a shell script) that causes the issue you see?
>
I think the point is that the group must be evaluated already in the search
for the AuthzTo attribute.
So my User A has the AuthzTo attribute set to User B and I have the
following access control:
access to *
by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test"
write
by * break
...
access to * attrs=authzTo
by self read
by * break
...
User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when
I log in as user A and proxyAuth to Openldap will evaluate the group
membership for A and cache it, during the search for the ACL to authzTo. A
is not member.
Now when the actual search operation takes places, openldap will used the
cached result (which was "is not member"), which is wrong because the user
has changed since the group membership was cached.
I hope this makes the problem more clear (I have a test environment here,
but it is very complex and easy transferable)
Gerald
** Virus checked by BB-5000 Mailfilter **
16 years, 6 months
RE: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de
>
> I have no objection at accepting this code, since it seems to
> create no backwards compatibility issues but rather solves a
> (irrelevant?) compatibility issue with an ancient version of
> the code in an area that I believe to be of questionable
> usefulness.
At least it had help me by upgrading a bunch of servers from 2.1 which used
this feature.
> In fact, ACIs have been deprecated ever since,
> so I wouldn't spend too much time with them. If there's no
> IPR issues (as, for what I can tell, there appear to be
> none), I'd try to apply the patch to HEAD code.
>
Thanks.
We use ACI, because we have a setup where we replicate different parts of
the tree to different slave ldap servers. By using ACI's the access
information get's replicated too. To get the same behaviour with ACL's it
would be much more compilcated, because we would need to sort out which
ACL's to replicate and which not, because not simply subtrees are replicated
(we cannot simply replicate all ACL's because this would leak too much
informations).
>From this point of view ACI are quite usefull, at least for us.
Gerald
** Virus checked by BB-5000 Mailfilter **
16 years, 6 months
Re: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by ando＠sys-net.it
richter(a)ecos.de wrote:
I have no objection at accepting this code, since it seems to create no
backwards compatibility issues but rather solves a (irrelevant?)
compatibility issue with an ancient version of the code in an area that
I believe to be of questionable usefulness. In fact, ACIs have been
deprecated ever since, so I wouldn't spend too much time with them. If
there's no IPR issues (as, for what I can tell, there appear to be
none), I'd try to apply the patch to HEAD code.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it
richter(a)ecos.de wrote:
> I noticed that when I use the proxyAuth control group members are not correctly
> resolved.
>
> What I do is to login as user A and do a search with proxyAuth control with an
> authzid of user B.
>
> User B is member of a group, which grants him access to the some items. User A
> is not.
>
> When directly logging in as user B, everything is ok. Using proxyAuth user B
> doesn't have access to the items that are granted to the group.
>
> The reason is that the group membership is cached, and therefore users A
> membership is used for ACL evaluation, instead of users B membership.
>
> The attached patch, simply deletes all cached groups, when inside the proxyAuth
> control setup, which resolvs this issue.
>
I'm not sure I understand the issue you describe. In fact, groups
appear to be cached on a per-operation basis, and user membership is
evaluated using the authorized identity (B in your case), so the
behavior should be correct. I've made a simple check using re23 and
things appear to work as expected: I log in as a user (A) that is not in
a group and authorize as a user (B) that is in that group. I previously
configured slapd so that only members of that group are allowed to read
an attribute in the whole db (say "cn"). Things work as expected: if I
login as user A I can't see "cn", but if I either log in as user B, or
login as user A and proxyAuthz as B I can read the "cn". Can you
provide a simple example (slapd.conf, db.ldif and sequence of
operations, e.g. in a shell script) that causes the issue you see?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
