Christian Kratzer wrote:
> Hi Michael,
>
> On Sat, 14 Dec 2013, Michael Ströder wrote:
>
>> HI!
>>
>> I used this FAQ entry to use set-based ACLs for my current task:
>>
>> http://www.openldap.org/faq/data/cache/1133.html
>>
>> There's written:
>>
>> "We could make this more powerful (and more complex and costly to compute)
>> by allowing base sets to be built from LDAP filters. This is something to
>> consider, because the combination of filters and sets (which have little
>> overlap in what they can express) is very powerful. This is partially provided
>> by the URI expansion capability."
>>
>> Was this ever implemented? It would be helpful. IMO using 'this' and/or 'user'
>> in [ldap://] sets would make evaluating the set-based <who> clause faster if
>> attributes used in LDAP URLs are properly indexed.
>>
>> Background:
>> My aim is to configure Linux clients all the same (search base, filter etc.)
>> but let each *machine* individually authenticate against OpenLDAP server.
>> Then only the users who are members of groups with login rights on this
>> particular server should be visible to the Linux client.
>> So the goal is to filter user/groups at the OpenLDAP server and *not* in the
>> Linux client (e.g. by sssd configuration or similar).
>> For now it seems only possible to do this with set-based ACLs given all the
>> requirements I have.
>
> I needed to restrict users seen be a spefic application to users that are
> member in the respective applications group.
>
> I cheated by not checking the group but the memberOf: attribute in the entries
> I intended to filter.
>
> olcAccess:
> to dn.children="dc=example,dc=org"
> filter="(memberOf=cn=application1-group,ou=groups,dc=example,dc=org)"
> by dn.base="cn=application1-user,ou=system,dc=example,dc=org" read
> olcAccess:
> to dn.children="dc=example,dc=org"
> filter="(memberOf=cn=application2-group,ou=groups,dc=example,dc=org)"
> by dn.base="cn=application2-user,ou=system,dc=example,dc=org" read
> olcAccess:
> to dn.children="dc=example,dc=org"
> filter="(memberOf=cn=application3-group,ou=groups,dc=example,dc=org)"
> by dn.base="cn=application3-user,ou=system,dc=example,dc=org" read
>
> The performance implictations of these kind of acl should be ok from my
> understanding as they only apply to the specific applications user.
Thanks for sharing your ACLs.
But in my case it's a strong requirement that ACLs are generic and do not
contain any names. So you in your case one could add more applications just by
adding entries without having to touch any ACLs at all.
AFAICT something like this can only be done with set-based ACLs.
Ciao, Michael.
HI!
I used this FAQ entry to use set-based ACLs for my current task:
http://www.openldap.org/faq/data/cache/1133.html
There's written:
"We could make this more powerful (and more complex and costly to compute)
by allowing base sets to be built from LDAP filters. This is something to
consider, because the combination of filters and sets (which have little
overlap in what they can express) is very powerful. This is partially provided
by the URI expansion capability."
Was this ever implemented? It would be helpful. IMO using 'this' and/or 'user'
in [ldap://] sets would make evaluating the set-based <who> clause faster if
attributes used in LDAP URLs are properly indexed.
Background:
My aim is to configure Linux clients all the same (search base, filter etc.)
but let each *machine* individually authenticate against OpenLDAP server.
Then only the users who are members of groups with login rights on this
particular server should be visible to the Linux client.
So the goal is to filter user/groups at the OpenLDAP server and *not* in the
Linux client (e.g. by sssd configuration or similar).
For now it seems only possible to do this with set-based ACLs given all the
requirements I have.
Ciao, Michael.
We upgraded from kernel 3.5 to 3.12.3 to update some of our benchmark numbers
and hit some major performance regressions, mainly because the kernel is
throttling processes that use too much CPU. This is definitely a kernel bug,
as the throttle mechanism belongs to the realtime scheduler and none of the
processes being affected had realtime priority when the throttle kicked in.
I've posted a query to the linux kernel mailing list but haven't gotten any
satisfactory answers yet. The same throttling behavior also occurs with
3.11.10, but there are no corresponding messages in the kernel log.
The email thread is here
http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/02313.html
A patch that may be related is described here
http://lkml.org/lkml/2013/5/29/640 which explains part of the observed
behavior, but not all of it (and indeed may be a red herring, unless it has
some interaction with the realtime scheduler).
There appear to be other serious networking related regressions in 3.12 as
well. http://lkml.indiana.edu/hypermail/linux/kernel/1312.1/02588.html
I recommend staying on 3.10 for production servers until this is sorted out.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
