[BUG] _list/indices API not working in 3.2

[GGJune413]

Describe the bug

In opensearch version 3.2, the GET _list/indices API fails due to lacking permissions for operations on system indices and the security index. This occurs even for users that have the all_access superuser role. The same operation does not fail using the GET _cat/indices API. This has the downstream effect of making ml-commons' ListIndexTool unusable, and since there is no CatIndexTool in version 3.2, prevents agents from viewing a cluster's indices.

Related component

Search:Query Capabilities

To Reproduce

1. Create a 3.2 cluster
2. Create a user with the all_access backend role
3. Attempt to run GET _list/indices

Expected behavior

GET _list/indices should return indices similar to _cat/indices

Additional Details

Plugins
Please list all plugins currently enabled.

analysis-icu
analysis-kuromoji
analysis-phonetic
analysis-smartcn
analysis-stempel
analysis-ukrainian
analysis-nori
ingest-attachment
mapper-size
mapper-murmur3
transport-reactor-netty4
opensearch-analysis-vietnamese-oracle
pluginsopensearch-job-scheduler
opensearch-index-management
opensearch-knn
opensearch-ml
opensearch-neural-search
opensearch-notifications-core
opensearch-notifications
opensearch-alerting
opensearch-sql
opensearch-reports-scheduler
opensearch-anomaly-detection
opensearch-observability
opensearch-security-analytics
opensearch-skills
opensearch-flow-framework
opensearch-ltr
prometheus-exporter
opensearch-asynchronous-search
opensearch-custom-codecs

Host/Environment (please complete the following information):

• Oracle Linux 9
• Version 1.42

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[andrross]

@cwperks Can you take a look? This might belong in the security repo if its a permission issue.

[cwperks]

Taking a look. I'll reply back later today with a summary of the issue and possible next steps.

[cwperks]

@GGJune413 what cluster settings are you using?

This is working for me

➜  ~ curl -XGET https://localhost:9200/_list/indices -k -u 'admin:myStrongPassword123!'
green open .opendistro_security VkwtgtlXQiy8eOCpmkQHQw 1 0 9 0 80.8kb 80.8kb
next_token null
➜  ~ curl -XGET https://localhost:9200/ -k -u 'admin:myStrongPassword123!'
{
  "name" : "smoketestnode",
  "cluster_name" : "opensearch",
  "cluster_uuid" : "zT6BcnZfRYiWjegR0caCcw",
  "version" : {
    "distribution" : "opensearch",
    "number" : "3.4.0-SNAPSHOT",
    "build_type" : "tar",
    "build_hash" : "00336141f90b2456d7aa35e9052fd6baf7147423",
    "build_date" : "2025-12-22T17:57:23.330243Z",
    "build_snapshot" : true,
    "lucene_version" : "10.3.2",
    "minimum_wire_compatibility_version" : "2.19.0",
    "minimum_index_compatibility_version" : "2.0.0"
  },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

[ThyTran1402]

I was able to reproduce this bug. The root cause is inheritance chain and pagination resolve explicit system index names. The OpenSearch security plugin treats the .opendistro_security index specially — even the all access role doesn't grant direct access to it. When the index is requested by wildcard, the security plugin silently excludes it. But when it's requested by explicit name (as the pagination strategy does), the security plugin denies access.

I can fix this and submit a PR to add filter to both pagination strategies. @cwperks @GGJune413

[ThyTran1402]

Hi @cwperks @andrross

Can someone please review the PR?

Thank you!