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@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@redhat.com
>     https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
>
>
> -- 
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
> Jenny Galipeau <jgali...@redhat.com>
> Principal Software QA Engineer
> Red Hat, Inc. Security Engineering
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel@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/



_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to