[Freeipa-devel] URI in HBAC

[Petr Spacek]

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.

-- 
Petr^2 Spacek