multi-valued ldap-group attributes in rlm_cache

[Arran Cudbard-Bell]

On 6 Aug 2014, at 09:18, Zenon Mousmoulas <zmousm at noc.grnet.gr> wrote:

> On 2014-08-05 06:34, Arran Cudbard-Bell wrote:
>> On 4 Aug 2014, at 09:33, Zenon Mousmoulas <zmousm at noc.grnet.gr> wrote:
>>> On 2014-08-02 15:58, Arran Cudbard-Bell wrote:
>>>>> I can see rlm_ldap populate control:Ldap-Group:
>>>>> Sat Aug  2 12:12:55 2014 : Debug: Added control:ldap_xyz-Ldap-Group with value "abc"
>>>>> Sat Aug  2 12:12:55 2014 : Debug: Added control:ldap_xyz-Ldap-Group with value "def"
>>>>> [...]
>>>>> But it looks like rlm_cache only caches the first value:
>>>>> Sat Aug  2 12:12:56 2014 : Debug: (4)   cache_xyz : Adding to cache entry:
>>>>> Sat Aug  2 12:12:56 2014 : Debug: (4)   cache_xyz : 	control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group -> 'abc'
>>>>> And the next cache lookup only shows the first value:
>>>>> Sat Aug  2 12:13:02 2014 : Debug: (9)   cache_xyz : Merging cached control list:
>>>>> Sat Aug  2 12:13:02 2014 : Debug: (9)   cache_xyz : 	ldap_xyz-Ldap-Group += 'abc'
>>>>> Is this supposed to work? I am using 3.0.4 rc1.
>>>> Yes, but I have a good idea why it's not.
>>> Would you please elaborate?
>> rlm_cache had a lot of attribute copying/moving logic that was
>> written before we did the map/template work in v3.0.x.
>> In the v3.0.x branch rlm_cache was switched to use the same code
>> as normal update blocks.
>> Normal update blocks behaved slightly differently, in that when
>> a += operator was used only the first instance of the referenced
>> (RHS) attribute was copied.
>> Seeing as people seem to prefer an explicit markup for saying
>> use all instances of a given attribute, instead of hacking
>> the update code to make it behave like rlm_cache, it's probably
>> better to add that markup now.
>> If you use the latest v3.0.x you should be able to do:
>> update {
>> 	control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group[*]
>> }
>> So now, essentially:
>> &ldap_xyz-Ldap-Group[0] and &ldap_xyz-Ldap-Group
>> are synonymous in terms of update blocks, not matter what the operator is.
>> Guess I should update the man page too.
>> Phil's 'any' prefix would have worked too, but it would have
>> meant hacking the config parser, and we already use [*] elsewhere.
> 
> So I have tested this and, like Andy Franks reported in the other thread, what I see is that freeradius hangs when it populates the cache with a multi-valued attribute using this syntax. It just gets stuck there:
> 
> Wed Aug  6 15:40:30 2014 : Debug: (4)   cache_koly.gr : Adding to cache entry:
> Wed Aug  6 15:40:30 2014 : Debug: (4)   cache_koly.gr : 	&control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group -> 'abc'
> Wed Aug  6 15:40:30 2014 : Debug: (4)   cache_koly.gr : Adding to cache entry:
> Wed Aug  6 15:40:30 2014 : Debug: (4)   cache_koly.gr : 	&control:ldap_xyz-Ldap-Group += &ldap_xyz-Ldap-Group -> 'def'
> 
> 
> Using v3.0.x head (e94616e).

Fixed. There was need to distinguish between inserting a single attribute
and inserting a bunch of linked attributes.

We're in sort of a weird transitional phase between linked lists and the
next thing.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140808/5f3b0325/attachment.pgp>