This is all happening on a standalone Splunk 6.3.4 search head. (It's a development environment, so my very few forwarders are all sending to the one system.)
I have a user, "resttest", who has only one role, "automation", assigned. That role does not inherit from "user" because I intend to limit its members' actions quite a bit and monitor for any inappropriate access (I'll be generating a report of whenever someone outside of the user role logs into Splunkweb instead of calling the REST API directly). I've been trying to get the capabilities right so that this user can actually access saved searches via REST API and have had no luck.
My search has these permissions in $SPLUNK_HOME/etc/apps/search/local.meta:
[savedsearches/test_search_permissions]
access = read : [ admin, automation, power ], write : [ admin ]
export = system
However, my resttest user (which is definitely in the "automation" role) receives an error when attempting to access the saved search endpoint:
In handler 'savedsearch': Could not find object id=test_search_permissions
This happens whether I access via:
/servicesNS/resttest/search/saved/searches/test_search_permissions
/servicesNS/nobody/search/saved/searches/test_search_permissions
/services/saved/searches/test_search_permissions
I'm able to access the saved search when using my own account.
I had assumed that my restricted "automation" role was simply missing a capability, but I've now cloned all of the capabilities from the "user" role and it's still unable to access the saved search.
Since the capabilities appear identical, I tried assigning the "resttest" user to the "user" role; it was then able to access the search endpoint via all three forms above. I then removed that role from that user (and tested; the saved search endpoints did not work) and added the "user" role instead to the inheritance for the "automation" role, and was once again able to see the saved search endpoint. In matching behavior, the user can see the search listed in /services/saved/searches when it's in the "user" role but not when it isn't.
I also captured the output of /services/authentication/current-context during each step above. They are identical except for the updated timestamps and, of course, the presence of user in the list in the latter two cases. The capabilities list returned is identical in all 3 configurations.
The roles/permissions must be working; the "user" role has no access to the search, so the system must be seeing that the user is in the "automation" role. The capabilities shown by the system are identical regardless of whether it's a member of the "user" role. I seem to be left with two options: I've managed to overlook something very basic and fundamental, or there's some kind of "special" attributes to the user role that I'm missing.
↧