Apache module:

On 04/26/2016 03:56 PM, Petr Spacek wrote:
> On 26.4.2016 15:16, Jan Pazdziora wrote:
>> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote:
>>>>> * For backwards compatibility, lack of URI in request means any URI is
>>>>> matched (as described in the design document). Is it a good idea? Any
>>>>> other solution?
>>>> For other attributes in HBAC rules, the lack of a value means nothing is
>>>> matched. To match anything, you have to set "${attribute}category" to 
>>>> "all". I
>>>> would prefer if URI matching was consistent with this, if it's possible.
>>> My understanding is that requests lacking URI parameter should not match any
>>> HBAC rules with non-empty URI. This will be backwards compatible because old
>>> clients will simply ignore new rules which cannot be evaluated properly 
>>> anyway
>>> (for lack of information in client's request).
>> The problem is that old clients will not ack for the new attributes
>> (they have no idea they should ask for them), so they will only see
>> parts of the HBAC rules.
>> So the question is -- what is the correct way to make sure that old
>> clients (that would not ask for the new attributes) are not served
>> any rules that have those new attributes set?
>>>> BTW what is the reason to split URIs into separate fields? If it's just 
>>>> case
>>>> sensitivity, I would like to point out that you can switch case 
>>>> sensitivity on
>>>> and off in the middle of a Perl regex using "(?i)" and "(?-i)".
>>> Personally I would rather see host+scheme+port split into separate 
>>> attributes.
>>> That would allow reporting like 'give me all rules for FTP' etc. without
>>> substring magic.
>>> And yes, I agree with Honza that multiple values should be evaluated as
>>> logical OR.
>>> E.g.
>>> schemes: {http, https, ftp, ftps}
>>> URI: /home/pspacek
>>> host: any
>>> allow: pspacek
>>> should grant user pspacek access to directory /home/pspacek on any host as
>>> long as the scheme is http/https/ftp/ftps.
>> So you propose cartesian product of the schemes and URI attributes
>> to be used?
> Yes.
> Before we can discuss this further we need to see current LDAP schema and
> code. Lukas, please share the code with us.

Lukas Hellebrandt
Associate Quality Engineer

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA:

Reply via email to