Strange Permission behavior

Before you post: Your responses to these questions will help the community help you. Please complete this template if you’re asking a support question.
Don’t forget to select tags to help index your topic!

1. Describe your incident:
I have a script that requests metrics via the API. And the token including the associated user just “lost” the permission to access one stream.
“Not authorized to access resource id <id of a stream(which is not new)>”

Due to this happening during tests I have the shell outputs of that stream explicitly working.
Even weirder: It’s not the first and that user does not have permission to specific streams anyways.

In fact no one has.

2. Describe your environment:

  • OS Information: Ubuntu 18.04.6 LTS

  • Package Version: 4.1.14+9e4b07c

  • Service logs, configurations, and environment variables:

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

In my despaired confusion I explicitly added the “streams:readall” permission.
The situation is too bizarre to make any sense of. No clue what I am supposed to do.

I did repeated tests with read only request (GET system/metrics) until the user lost access.
Of course I checked if user and token still exist. I also logged in as the User. Same problem. The user just lost access somehow.

Since I was still logged in the webinterface as my admin user I could see that nothing seemed to have changed there, roles, streams nothing seems to have changed.

4. How can the community help?

Best guess?
Maybe there is some weird permission cache thing going on and the user in question was never supposed to have access in that configuration?
Maybe I added a role too many?

Can a user lose access to something just by receiving an additional role?

Since “streams:readall” presumably did nothing, what is it supposed to do?
Is there a way to give a non admin read access to all streams?
Listing them individually will always be limited to streams that exist at the point of definition of the role.

Hello && Welcome @daniel2

Ill try to answer these questions. This is odd situation, it seams like Graylog is not responding your request on permissions configurations.

Check GL/ES & MongoDb log files when trying to access this stream. Perhaps there is a clue on what’s going on.

Yes, for the stream in question. Its called a “Share”.

I don’t think that answers my question.

I want a way to give access to all streams not make 1 stream accessible for everyone.

Graylog logs only give me basically the same message. Which is what led me to the conclusion that the most likely cause would be some kind of permission caching where the user in the current setup should never have had access to the streams. Thus my questions on how the permissions are supposed to look like if I want to do this.

What permissions does a user require to read all of the streams? I mean “all streams” as the meta construct of “all streams existing (currently and in the future) on Graylog” not: ‘one stream that is named “all stuff/events/data/etc”’. Plus I explicitly don’t want to name the streams individually. So that it won’t break just because one was added or changed later on.

This is intended to be the permission level for the monitoring system. Therefore it will always require complete read access no matter what has changed.

I will now check mongoDB and elasticsearch logs.

I revisited my saved history and noticed what can only be described as an embarrassing lapse of concentration:
The lack of permission was from a different script one step up in the shell history I executed instead of the correct one.
There probably never was an error, all my mistake I apparently pressed the up arrow one too many times without noticing.

In that case:
I assume the pre-defined group “Reader” has the permissions I asked for.

It happens, glad you resolved your issue.

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