On 26.4.2016 12:57, Jan Cholasta wrote: > Hi, > > On 25.4.2016 14:48, Lukáš Hellebrandt wrote: >> http://www.freeipa.org/page/V4/URI-based_HBAC >> >> I have made some important changes to the design document of this >> proposed feature. The difference is mainly changing regular expression >> interpretation of URI to longest-prefix matching. >> >> This change was done mainly because of upstream's reactions. I value any >> further comments and particularly discussion about the two topics >> mentioned at the end of the design page: >> >> * 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). >> * How about multiple URI's in one HBAC rule? Is it a good idea? How to >> interpret combinations of host+scheme+port (one field) and URI paths >> (another field) in that case? > > I think it is not only good idea, but actually necessary. I guess you would > have to consider an URI matched if it's host+scheme+port matches any of the > host+scheme+port patterns and at the same time it's path matches any of the > path patterns. > > 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. -- 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