icinga2 icon indicating copy to clipboard operation
icinga2 copied to clipboard

ObjectQueryHandler: Check user permissions on joined relations

Open yhabteab opened this issue 3 years ago • 3 comments

fixes #9339

yhabteab avatar Jun 20 '22 13:06 yhabteab

Riddle 1

Isn't that obvious to you? When you specify the same permission 10K times with a callable filter, what would you expect to happen? I also get a stack overflow error but that is not something being added by this PR. Just try querying the CheckCommands directly and see what happens there.

[2022-07-22 11:31:32 +0200] information/ApiListener: New client connection from [::ffff:127.0.0.1]:50112 (no client certificate)
Stack overflow while evaluating expression: Recursion level too deep.
[2022-07-22 11:31:32 +0200] information/HttpServerConnection: Request: GET /v1/objects/checkcommands (from [::ffff:127.0.0.1]:50112), user: dummy, agent: curl/7.79.1, status: Not Found).
[2022-07-22 11:31:32 +0200] information/HttpServerConnection: HTTP client disconnected (from [::ffff:127.0.0.1]:50112)

Riddle 2

Yep, need to cache the permission filter of the individual types as well.

yhabteab avatar Jul 22 '22 09:07 yhabteab

Isn't that obvious to you?

Oh, I exactly know why is what happening here. That’s why I called it a riddle. :-)

When you specify the same permission 10K times with a callable filter, what would you expect to happen? I also get a stack overflow error but that is not something being added by this PR.

Absolutely. But Icinga even manages to properly handle that (pseudo) stack overflow. So not leaking memory is the least thing Icinga shall do. I'm joining check commands and only they have a such filter, so your join permission check is clearly responsible. Also I have no doubt it also works with a smaller filter, but mine leaks memory faster.

Al2Klimov avatar Jul 25 '22 09:07 Al2Klimov

Riddle 2

Still happening.

Al2Klimov avatar Jul 25 '22 11:07 Al2Klimov