I think this issue has been sorted out. The short answer is that yes, quotas are inherited, so a quota set for a role should apply to a role that inherits the first role. Offically, Splunk support states: "Role combining is always done in a 'most permissive' fashion. So if the user has multiple roles, we take the maximum of the quota across
those roles."
In my examples above, "roleB" would inherit the disk quota assigned to "roleA" if roleB imports roleA, and users in DepartmentOne and DepartmentTwo would inherit the the quotas assigned to the My_Company_User role.
The answer to the second part of the question is that no, there is no way to view one's own quotas or the per-user quotas through the UI, nor any good way to check this in 4.1. A new feature in 4.2 is supposedly the ability to check roles via REST endpoints, but I haven't had time to confirm this.
Lastly, for the curious, the issue that actually triggered the quotas not working properly in my environment was one of case sensitivity in declaring role names. In Splunk 3.4, role names were by default in camel case, and we propagated this to the authorize.conf in our 4.1 environment. But, in either 4.0 or 4.1, a new restriction was placed on role names, and they must now be only in lower case.
From:
http://www.splunk.com/base/Documentation/latest/admin/Addusersandassignroles :
Note: Role names must use lowercase characters. For example: "admin", not "Admin". User names, however, are entirely case-insensitive: "Jacque",
"jacque", "JacQue" are all the same to Splunk.
At some point, an edit of the role via the UI was made, and the UI split the role when writing to authorize.conf -- we wound up with one version of the role that had the camel-cased role name and the correct configs, and another that had an all lower case role name, and incomplete configs. The import statement preferred the lower case role over the camel case stanza, and the quotas were therefore not imported properly.
... View more