On Mon, Feb 29, 2016 at 04:29:05PM +0100, Jan Pazdziora wrote:
On Mon, Feb 29, 2016 at 03:30:12PM +0100, Jakub Hrozek wrote:
So, effectively, there would be no way to make some URI accessible to more than one group?
There is nothing preventing you from adding more groups to a single rule..
But with the evaluation you've outlined, it's only to place additional restriction on the rule, isn't it?
Nope, that's not how the groups work. I have a rule on my test IPA server that looks like this: Rule name: ad_allowed_rhel5 Enabled: TRUE User Groups: ad_allowed, admins Hosts: unidirect.ipa.test, centos5.ipa.test, nss-pam-ldapd.ipa.test Services: system-auth, su, su-l
Anyone from group ad_allowed or group admins can log in to the hosts listed in the rule with su, su-l or system-auth PAM services.
Still, this beats creating deny rules. Every single time we added deny rules in any form or shape to sssd we ended up regretting that decision after some time..
(One repeating reason is that a failure to evaluate an allow rule causes a denial of service at worst, a failure to evalute a deny rule is a
Is the problem really evaluating the rule or finding the rule? I thought our biggest worry is that the rule will not be seen at all.
And if we require all rules to pass, failure to find the last rule (and evaluate) when all previous have passed, will allow the access. To me, requiring all ruless to pass means that each additional rule is an effective deny on anything it does not match. Yes, if we are aware of the rule existence, we deny the access at worse, but if we miss the rule existence altogether, we've just granted access we were not supposed to grant.
But I guess I understand where we're talking past one another -- is it when the URIs overlap?
Yes, in that case you're right..