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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code