A user ID has thousands of minidisks that are a pool of space that we assign dynamically automatically. The id that owns all the disks has these rules:
REJECT * LINK 191 *
ACCEPT * LINK 192 RR (NOPASS
ACCEPT * LINK * * ( NOPASS
The intent is to deny access to the 191 disk, grant read access to 192, and full/whatever access to everything else instead of listing thousands of individual rules to grant MW access.
The interesting thing here is when the two ACCEPT rules are in the other order, I get a warning:
VMXACR0174W USER rule: ACCEPT * LINK * * ( NOPASS
VMXACR0175I Overrides USER rule: ACCEPT * LINK 192 RR (NOPASS
but when the rules are in the above order, there is no warning. That makes me think there's no ambiguity and things work as I intended.
However, to test, I logged onto a regular, nothing-special-about-it user ID and tried CP LINK ID 192 300 MW
Lo and behold, the link completed and I have MW access.
My expectation was the more specific rule would apply to the 192 disk, instead of the very generic rule overriding it.
VM:Secure 3.2
There are a couple things to consider when doing rule set up and QRULES querying.
1. ACCEPT * LINK 192 RR does NOT mean any other link mode will be rejected. It means a RR link will be accepted by this rule then VM:Secure will continue to look for a match to ACCEPT or REJECT. So if you want all other links to be rejected put:
ACCEPT * LINK 192 RR
followed by
REJECT * LINK 192 *
Summary: Lack of an ACCEPT doesn't mean a REJECT when you are configured for NORULE ACCEPT. You must specifically reject anything you don't want, or configure NORULE REJECT.
2. When doing QRULES pretend that LINK is being presented to VM:Secure by CP. CP always has a link mode in the ACI request so you must do the same with QRULES.
In this example:
vmsecure qrules dizzy5 link vpool 192
will get the response you expect when you issue:
VMSECURE QRULES DIZZY5 LINK VPOOL 192 RR
By not specifying the link mode your query is ambiguous and VM:Secure won't match on the RR rule. You have to do those QRULE commands like the request would come in via CP, with the mode supplied (for LINK for example).
You may also need to add some REJECT records to make sure you don't have some security holes. Keep in mind you can use the system default rules file to stop things too when there aren't rules.
For instance:
REJECT * LINK * * in the system default rules file will stop any links not accepted in the system rules, group rules, user rules, and group default rules. Remember the rule file hierarchy for strategic rule placement.
Here's a link to a section in the VM:Secure Rules Reference guide for Combining Rules that you may find helpful;