Splunk Search

Restful API: cannot change the 'removable' attribute of savedchanges

patng_nw
Communicator

Below is the Bash script to change the ACL of a saved search:

URL="https://splunksearch3.shatin.link:8089/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/acl"
NEW_OWNER="user1"
READ="batch,teamA"
WRITE="teamB"
curl -k -u admin:$PWD $URL -d owner=$NEW_OWNER -d perms.read=$READ -d perms.write=$WRITE \
-d removable=1 -d sharing="global"

I found that I cannot change the removable attribute. After running the script, the permissions and owner are set correctly, but not the removable, it remains 0, as shown in the response below.

<?xml-stylesheet type="text/xml" href="/static/atom.xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:s="http://dev.splunk.com/ns/rest" xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/">
  <title>savedsearch</title>
  <id>https://splunksearch3.shatin.link:8089/servicesNS/nobody/search_migration_app/saved/searches</id>
  <updated>2019-02-13T12:47:43+08:00</updated>
  <generator build="06d57c595b80" version="7.2.3"/>
  <author>
    <name>Splunk</name>
  </author>
  <link href="/servicesNS/nobody/search_migration_app/saved/searches/_new" rel="create"/>
  <link href="/servicesNS/nobody/search_migration_app/saved/searches/_reload" rel="_reload"/>
  <link href="/servicesNS/nobody/search_migration_app/saved/searches/_acl" rel="_acl"/>
  <opensearch:totalResults>1</opensearch:totalResults>
  <opensearch:itemsPerPage>30</opensearch:itemsPerPage>
  <opensearch:startIndex>0</opensearch:startIndex>
  <s:messages/>
  <entry>
    <title>discuss-user-vt-count</title>
    <id>https://splunksearch3.shatin.link:8089/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count</id>
    <updated>2019-02-13T12:47:43+08:00</updated>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count" rel="alternate"/>
    <author>
      <name>user1</name>
    </author>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count" rel="list"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/_reload" rel="_reload"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count" rel="edit"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/disable" rel="disable"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/dispatch" rel="dispatch"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/embed" rel="embed"/>
    <link href="/servicesNS/nobody/search_migration_app/saved/searches/discuss-user-vt-count/history" rel="history"/>
    <content type="text/xml">
      <s:dict>
        <s:key name="eai:acl">
          <s:dict>
            <s:key name="app">search_migration_app</s:key>
            <s:key name="can_change_perms">1</s:key>
            <s:key name="can_list">1</s:key>
            <s:key name="can_share_app">1</s:key>
            <s:key name="can_share_global">1</s:key>
            <s:key name="can_share_user">0</s:key>
            <s:key name="can_write">1</s:key>
            <s:key name="modifiable">1</s:key>
            <s:key name="owner">user1</s:key>
            <s:key name="perms">
              <s:dict>
                <s:key name="read">
                  <s:list>
                    <s:item>batch</s:item>
                    <s:item>teamA</s:item>
                  </s:list>
                </s:key>
                <s:key name="write">
                  <s:list>
                    <s:item>teamB</s:item>
                  </s:list>
                </s:key>
              </s:dict>
            </s:key>
            <s:key name="removable">0</s:key>
            <s:key name="sharing">global</s:key>
          </s:dict>
        </s:key>
      </s:dict>
    </content>
  </entry>
</feed>

How can I change the ACL's removable attribute thru RESTFUL API? I need to do that as it's part of a migration process.

Tags (1)
1 Solution

mbadhusha_splun
Splunk Employee
Splunk Employee

Hey Patrick,

Further checking, found that "removable" is not a property that can be set, this is what the permissions are on the object for the user doing the call. they are calculated based on the sharing permissions (ACLs) of the app/category/object.

"removable" is set based on the config it is coming from default or local.

That means, if you have a saved search saved in a default directory/location, then the "removable" is set to 0 and for the saved search in local directory it is set to 1.

You can run the below search on your search head for the respective saved searches to find out what the removable property has been set to.

SPL:

| rest /servicesNS/admin/search/saved/searches/ | table id eai*

Check for "eai:acl.removable" property in the saved search and verify from which location the saved search is saved.

The default ones will have removable=0, the local ones 1. And this is not a property you can set, it’s just the system letting you know what you can do to that object

i.e. If you want a search to not be removable. it needs to be in a default folder rather than a local folder.

However, you can change permissions to make a user not be able to remove an object, sure, but you won’t be changing “removable” directly, instead you would be changing the write permission on the container for that user/role as that controls whether a user can delete things inside that container.

REF:

https://docs.splunk.com/Documentation/Splunk/7.2.3/Knowledge/Disableordeleteknowledgeobjects

Hope the above helps!

View solution in original post

mbadhusha_splun
Splunk Employee
Splunk Employee

Hey Patrick,

Further checking, found that "removable" is not a property that can be set, this is what the permissions are on the object for the user doing the call. they are calculated based on the sharing permissions (ACLs) of the app/category/object.

"removable" is set based on the config it is coming from default or local.

That means, if you have a saved search saved in a default directory/location, then the "removable" is set to 0 and for the saved search in local directory it is set to 1.

You can run the below search on your search head for the respective saved searches to find out what the removable property has been set to.

SPL:

| rest /servicesNS/admin/search/saved/searches/ | table id eai*

Check for "eai:acl.removable" property in the saved search and verify from which location the saved search is saved.

The default ones will have removable=0, the local ones 1. And this is not a property you can set, it’s just the system letting you know what you can do to that object

i.e. If you want a search to not be removable. it needs to be in a default folder rather than a local folder.

However, you can change permissions to make a user not be able to remove an object, sure, but you won’t be changing “removable” directly, instead you would be changing the write permission on the container for that user/role as that controls whether a user can delete things inside that container.

REF:

https://docs.splunk.com/Documentation/Splunk/7.2.3/Knowledge/Disableordeleteknowledgeobjects

Hope the above helps!

damien_chillet
Builder

Hi @mbadhusha_splunk

Above is very useful - though i have a similar problem with some lookups.
How is removable attribute set for lookups since they're all under the same lookups directory (no default/local)?

When i check

| rest /servicesNS/-/-/data/lookup-table-files

For two lookup in the same app, I see all the attributes are the same except for eai:acl.can_share_user and eai:acl.removable (both set to 0 vs both set to 1)

0 Karma

CycloneCteve
Engager

I had the same issue which started after a recent upgrade when I mistakenly restored a backup from a search head to the deployer and then deployed that bundle using the full push mode. This created a default.meta file in each search head app which - despite not having a removable property in each lookup's stanza - changed the endpoint "removable" property to 0.

curl -k -u admin:password https[:]//localhost:8089/servicesNS/<lookup  owner>/<app name>/data/lookup-table-files/<lookup file.csv>

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xml" href="/static/atom.xsl"?>
<feed xmlns="http[:]//www.w3.org/2005/Atom" xmlns:s="http[:]//dev.splunk.com/ns/rest" xmlns:opensearch="http[:]//a9.com/-/spec/opensearch/1.1/">
  <title>lookup-table-files</title>
  <id>https[:]//localhost:8089/servicesNS/<lookup owner>/<app name>/data/lookup-table-files</id>
  <updated>2021-08-18T15:05:43-06:00</updated>
  <generator build="*****" version="8.2.1"/>
  <author>
    <name>Splunk</name>
  </author>
  <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/_new" rel="create"/>
  <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/_reload" rel="_reload"/>
  <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/_acl" rel="_acl"/>
  <opensearch:totalResults>1</opensearch:totalResults>
  <opensearch:itemsPerPage>30</opensearch:itemsPerPage>
  <opensearch:startIndex>0</opensearch:startIndex>
  <s:messages/>
  <entry>
    <title><lookup file.csv></title>
    <id>https[:]//localhost:8089/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv></id>
    <updated>2021-08-18T12:50:10-06:00</updated>
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>" rel="alternate"/>
    <author>
      <name><lookup owner></name>
    </author>
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>" rel="list"/>
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>/_reload" rel="_reload"/>
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>" rel="edit"/>
	<!-- The following two links were missing from the response; pulled from a working lookup
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>" rel="remove"/>
    <link href="/servicesNS/<lookup owner>/<app name>/data/lookup-table-files/<lookup file.csv>/move" rel="move"/> -->
    <content type="text/xml">
      <s:dict>
        <s:key name="disabled">0</s:key>
        <s:key name="eai:acl">
          <s:dict>
            <s:key name="app"><app name></s:key>
            <s:key name="can_change_perms">1</s:key>
            <s:key name="can_list">1</s:key>
            <s:key name="can_share_app">1</s:key>
            <s:key name="can_share_global">1</s:key>
            <s:key name="can_share_user">0</s:key>
            <s:key name="can_write">1</s:key>
            <s:key name="modifiable">1</s:key>
            <s:key name="owner"><lookup owner></s:key>
            <s:key name="perms">
              <s:dict>
                <s:key name="read">
                  <s:list>
                    <s:item>*</s:item>
                  </s:list>
                </s:key>
                <s:key name="write">
                  <s:list>
                    <s:item>power</s:item>
                  </s:list>
                </s:key>
              </s:dict>
            </s:key>
            <!-- Here is the problem property: -->
            <s:key name="removable">0</s:key>
            <s:key name="sharing">app</s:key>
          </s:dict>
        </s:key>
        <s:key name="eai:appName"><app name></s:key>
        <s:key name="eai:attributes">
          <s:dict>
            <s:key name="optionalFields">
              <s:list/>
            </s:key>
            <s:key name="requiredFields">
              <s:list>
                <s:item>eai:data</s:item>
              </s:list>
            </s:key>
            <s:key name="wildcardFields">
              <s:list/>
            </s:key>
          </s:dict>
        </s:key>
        <s:key name="eai:data"><![CDATA[/opt/splunk/etc/apps/<app name>/lookups/<lookup file.csv>]]></s:key>
        <s:key name="eai:userName"><lookup owner></s:key>
      </s:dict>
    </content>
  </entry>
</feed>


After reading mbadhusha_splun's answer, I realized SOME config was overriding the desired config, but there is no lookups.conf. So, I tried renaming /opt/splunk/etc/apps/<app name>/metadata/default.meta on the impacted apps to default.meta_bak on each search head and then restarting them. This resolved our problem! I have some cleanup to do, but the lessons for me were A) change push deploy mode with CAUTION and B) default.meta somehow overrides local.meta.

Get Updates on the Splunk Community!

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...

New in Observability Cloud - Explicit Bucket Histograms

Splunk introduces native support for histograms as a metric data type within Observability Cloud with Explicit ...