Content Packs and Permissions

Graylog Central (peer support)
1

1. Describe your incident:

A non-administrative user tries to create a content pack in the web UI by navigating to system/contentpacks, clicking “Create a Content Pack”, setting Name, Summary, and Vendor to “foo” and selecting a single Grok pattern. The non-admin user then clicks “Next”.

At this point “Missing Permissions” is displayed with the specific error

The permissions check for the following request failed,
while trying to access /system/contentpacks/create.
There was an error fetching a resource: Forbidden. Additional information: Not authorized

There os nothing responsive to this in the logs

2. Describe your environment:

  • OS Information: Kubernetes/helm
  • Package Version: 2.1.3
  • Service logs, configurations, and environment variables: Nothing of note

The user has broad permissions, but lacks Admin:

image
image1658×924 98.4 KB

The “Power User” role contains:

$ curl http://graylog:9000/api/authz/roles -X GET -H "X-Requested-By: cli" -u admin:AdministratorPassword -sS | jq '.roles[] | select(.name == "Power User")'

{
  "id": "62bb485f292b91331d5ef92c",
  "name": "Power User",
  "description": "Power Users can do everything except admin GrayLog itself",
  "permissions": [
    "clusterconfigentry:read",
    "pipeline:*",
    "authhttpheaderconfig:read",
    "sidecar_collector_configurations:read",
    "users:read",
    "aws:read",
    "journal:read",
    "licenseinfos:read",
    "eventdefinitions:*",
    "systemjobs:read",
    "authservicebackend:read",
    "dashboards:*",
    "sources:read",
    "notifications:read",
    "collectors:read",
    "lookuptables:read",
    "searches:*",
    "inputs:read",
    "loggersmessages:read",
    "decorators:*",
    "sidecar_collectors:read",
    "fieldnames:read",
    "contentpack:*",
    "eventnotifications:*",
    "jvmstats:read",
    "throughput:read",
    "pipeline_rule:*",
    "stream_outputs:*",
    "messages:*",
    "messagecount:read",
    "view:*",
    "systemmessages:read",
    "indexsets:read",
    "streams:*",
    "catalog:list",
    "outputs:read",
    "default-view:set",
    "authserviceglobalconfig:read",
    "indexercluster:read",
    "pipeline_connection:*",
    "sidecars:read",
    "urlwhitelist:read",
    "roles:read",
    "deflector:read",
    "grantsoverview:read",
    "buffers:read",
    "indexranges:read",
    "system:read",
    "indices:read",
    "metrics:*",
    "loggers:read"
  ],
  "read_only": false
}

3. What steps have you already taken to try and solve the problem?

  • Careful audit of the permissions
  • Looking for responsive log output
  • Trying to determine if content packs are expected to be able to be created by non-admin users

4. How can the community help?

Answer these questions or otherwise provide insight on how to continue debug:

  • Should I be able to create a content pack as a non-admin user?
  • What permissions are required to do so?
  • How can I tell which permission is required for a specific operation?

Thank you!

2

Hello @hstenzel

To be honest, Not sure. I did go through my lab Enterprise/Operation/Open versions.
Only idea I have is to insure if the GROK is on a input, make sure the Non Admin user can access it.
Next idea, perhaps ask that here. I assume this would be a security issue, so one has to be an admin to create content pack, but not 100% sure.

3

@gsmith Thanks for the response.

A few more details I neglected to include in my original report:

First, the type of object selected does not matter. I’ve also attempted with a dashboard I created with that user and I have the same result.

Next, it is possible to work with content packs as a sufficiently-provisioned non-admin user. For instance, I can create a new version of an existing content pack and download it successfully. It’s just that I cannot create a new content pack. This suggests that the contentpack:* permission is otherwise working properly.

I appreciate the suggestion to open an issue. I’ve done that: non-admin user cannot create content pack · Issue #12981 · Graylog2/graylog2-server · GitHub

4

I found the issue, posting for the benefit posterity.

In actual fact, the api that fails is a POST to api/system/catalog despite the error message naming /system/contentpacks/create.

Granting catalog:resolve in addition to catalog:list corrects this issue.

I’d still really like to know how I can more effectively debug permissions problems, but I’m unblocked.

Thank you!

1 Like
5

Noce :+1:
and thanks for posting your resolve to the issue. But in all, I don’t think one should have to do that, think this perhaps a bug.

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.