[Freeipa-devel] [WIP] Add command to test HBAC rules
Dmitri Pal
dpal at redhat.com
Mon Jul 25 14:19:17 UTC 2011
On 07/25/2011 10:06 AM, Jenny Galipeau wrote:
>
>
> ------------------------------------------------------------------------
>
> On 07/25/2011 07:59 AM, Alexander Bokovoy wrote:
>
> On 22.07.2011 23:10, Alexander Bokovoy wrote:
>
> So this is a little confusing. I thought --rules limited the rules that
> were considered. Maybe I'm misunderstanding it.
>
> --validate + --rules gives limitation, --rules alone adds more rules to
> the existing test set which is all enabled rules in IPA.
>
> I reworked a bit command line interface to avoid confusion like that.
>
> # ipa hbactest --help
> Usage: ipa [global-options] hbactest [options]
>
> Options:
> -h, --help show this help message and exit
> --user=STR User name
> --srchost=STR Source host
> --host=STR Target host
> --service=STR Service
> --rules=LIST Rules to test. If not specified, all enabled rules are
> tested
> --detail Detail rule execution
> --all Include all enabled IPA rules into test
>
> Now if you specify --rules, hbactest will only try to simulate login
> using these rules. You would need to add --all to force considering all
> IPA enabled rules.
>
>
> I like the functionality but --all does not sound right, may be it
> should be --enabled or something else.
>
> how about :
> --disabled
> --all (both enabled and disabled)
>
> and default without specifying either would be just enabled.
>
>
> When no --rules are specified, simulation is run against all enabled IPA
> rules.
>
> --validate got replaced by --detail which simply tries to run simulation
> one by one and report results for each rule. You can apply it for any
> run, with or without --rules and --all.
>
>
> May me --detail should something like --each or --checkeach or
> --iterate. The expectation about the term "detail" is a bit
> different. The functionality seems OK though.
>
>
> I too am confused with --detail. What does "Detail rule execution"
> mean? I do not like --iterate, this is a developer term and not
> specific to what the user should expect as a behavior.
>
>
> If --rules contains a name of non-existent rule, it is simply ignored.
> So if I asked to verify against --rule=foobar where there is no such
> rule, Should there be error message for such cases? Right now you'll get
> False (access is not granted) and --detail will not show any rules.
>
>
> It should be an error IMO. The reason is that you might have
> miss-typed something and think you checked the rule that you
> miss-typed but it would turn out that you did not.
>
>
> +1 error - this would match the behavior of all other CLIs.
>
>
> Now, the only mode left out is batch verification of all disabled rules
> for purpose of checking their correctness.
>
>
> The more I think about it the more I lean towards just having
> --disabled to include all disabled rules instead of listing them
> explicitly in --rules. It is more a convenience aggregation than
> any different in behavior.
>
> Again ...
>
> how about :
> --disabled
> --all (both enabled and disabled)
>
> and default without specifying either would be just enabled.
>
>
> Suppose we have a switch
> --show-invalid that takes all IPA rules and runs a simulation request
> against them, reporting the ones that are invalid only.
>
>
> Invalid in what way? I am not sure we can detect validity of the
> rules. The whole point of the tool was to detect whether a real or
> test user will be denied or allowed and whether it is expected or not.
>
> Such a request
> could be done without any specific (user, source host, target host,
> service) tuple because we are only interested in HBAC_EVAL_ERROR return
>
>
> I am not sure I understand. What kind of condition would return
> such an error?
>
> code which is independent of input parameters. Unfortunately all we can
> tell in this case is that rule is incorrect, without much details.
> Probably some improvement for libipa_hbac is needed, like converting
> request result into a bit field and returning detailed cause of error
> per tuple element.
>
>
> Current version is attached. It still lacks unit tests.
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
>
> --
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
>
>
> --
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
> Jenny Galipeau <jgalipea at redhat.com>
> Principal Software QA Engineer
> Red Hat, Inc. Security Engineering
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
How about:
--all means all rules
--enabled means all enabled rules; it can be used with the specific
values like this --enabled=A,B,C then it will include only those enabled
rules
--disabled means all disabled rules; it can be used with the specific
values like this --disabled=X,Y,Z then it will include only those
disabled rules
Eliminate --rules.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20110725/4e4ef4e2/attachment.htm>
More information about the Freeipa-devel
mailing list