starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

[PR #7676] [MERGED] Fix #7399: LDAP excessive CPU usage when AUTH_LDAP_FIND_GROUP_PERMS is enabled #13265

New Issue
Closed
opened 2025-12-29 22:26:25 +01:00 by adam · 0 comments
adam commented 2025-12-29 22:26:25 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/netbox-community/netbox/pull/7676
Author: @kkthxbye-code
Created: 10/28/2021
Status: ✅ Merged
Merged: 11/18/2021
Merged by: @jeremystretch

Base: develop ← Head: develop

📝 Commits (1)

  • 830cf4b Fix #7399 - LDAP using excessive CPU when AUTH_LDAP_FIND_GROUP_PERMS is enabled

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 netbox/netbox/authentication.py (+1 -1)

📄 Description

Fixes: #7399

This should fix the excessive CPU usage when enabling AUTH_LDAP_FIND_GROUP_PERMS and having a combination of many object permissions and many users in the same group.

First, this is not an optimal fix, feel free to close the PR if a better fix is suggested. The reason for the bad performance is the filter added in 82300990ec:

82300990ec/netbox/netbox/authentication.py (L174-L180)

When added to the original query:

82300990ec/netbox/netbox/authentication.py (L23-L34)

The resulting SQL is essentially:

SELECT "users_objectpermission".*
FROM "users_objectpermission"
LEFT OUTER JOIN "users_objectpermission_users" ON ("users_objectpermission"."id" = "users_objectpermission_users"."objectpermission_id")
LEFT OUTER JOIN "users_objectpermission_groups" ON ("users_objectpermission"."id" = "users_objectpermission_groups"."objectpermission_id")
LEFT OUTER JOIN "auth_group" ON ("users_objectpermission_groups"."group_id" = "auth_group"."id")
LEFT OUTER JOIN "auth_user_groups" ON ("auth_group"."id" = "auth_user_groups"."group_id")
WHERE (("users_objectpermission_users"."user_id" = 1
        OR "auth_user_groups"."user_id" = 1
        OR "auth_group"."name" IN (
                                   'netbox-user',
                                   'group1',
                                   'group2'
                                   ))
       AND "users_objectpermission"."enabled")
ORDER BY "users_objectpermission"."name" ASC;

The outer join for auth_user_group essentially duplicates each users_objectpermission row once for each other user that is allocated to one of the groups not filtered out in the auth_group join.

In my test instance, with 327 objectpermissions in the netbox-user group, 30 other users has that same group, which makes the query return 30 duplicates per objectpermission totalling 9810 permissionobjects. The fix caused a load of the rack page with 50 objects per page to decrease from 1400 ms to 600 ms.

I'm not sure how to fix it in a smart way, as I have a hard time seing how the relationship is supposed to work. Even the original query is iffy I think, as I'm pretty sure it can return duplicate permissions as well if user bound objectpermissions are used.

The fix just makes the postgres remove the duplicates, which fixes the performance regression when using AUTH_LDAP_FIND_GROUP_PERMS. The query time increase should be negligible even in extreme cases.

Still someone should probably rework the queries.

Note: While the fix is pretty straightforward and I can't see how it could mess anything up, I would appreciate if someone else could test it before deciding to merge.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/netbox-community/netbox/pull/7676 **Author:** [@kkthxbye-code](https://github.com/kkthxbye-code) **Created:** 10/28/2021 **Status:** ✅ Merged **Merged:** 11/18/2021 **Merged by:** [@jeremystretch](https://github.com/jeremystretch) **Base:** `develop` ← **Head:** `develop` --- ### 📝 Commits (1) - [`830cf4b`](https://github.com/netbox-community/netbox/commit/830cf4b31f6036c4ca17422d9bace348f034c41e) Fix #7399 - LDAP using excessive CPU when AUTH_LDAP_FIND_GROUP_PERMS is enabled ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `netbox/netbox/authentication.py` (+1 -1) </details> ### 📄 Description ### Fixes: #7399 This should fix the excessive CPU usage when enabling AUTH_LDAP_FIND_GROUP_PERMS and having a combination of many object permissions and many users in the same group. First, this is not an optimal fix, feel free to close the PR if a better fix is suggested. The reason for the bad performance is the filter added in 82300990ec79f8ce6b2fca953d5548028a14aaea: https://github.com/netbox-community/netbox/blob/82300990ec79f8ce6b2fca953d5548028a14aaea/netbox/netbox/authentication.py#L174-L180 When added to the original query: https://github.com/netbox-community/netbox/blob/82300990ec79f8ce6b2fca953d5548028a14aaea/netbox/netbox/authentication.py#L23-L34 The resulting SQL is essentially: ```sql SELECT "users_objectpermission".* FROM "users_objectpermission" LEFT OUTER JOIN "users_objectpermission_users" ON ("users_objectpermission"."id" = "users_objectpermission_users"."objectpermission_id") LEFT OUTER JOIN "users_objectpermission_groups" ON ("users_objectpermission"."id" = "users_objectpermission_groups"."objectpermission_id") LEFT OUTER JOIN "auth_group" ON ("users_objectpermission_groups"."group_id" = "auth_group"."id") LEFT OUTER JOIN "auth_user_groups" ON ("auth_group"."id" = "auth_user_groups"."group_id") WHERE (("users_objectpermission_users"."user_id" = 1 OR "auth_user_groups"."user_id" = 1 OR "auth_group"."name" IN ( 'netbox-user', 'group1', 'group2' )) AND "users_objectpermission"."enabled") ORDER BY "users_objectpermission"."name" ASC; ``` The outer join for auth_user_group essentially duplicates each users_objectpermission row once for each other user that is allocated to one of the groups not filtered out in the auth_group join. In my test instance, with 327 objectpermissions in the netbox-user group, 30 other users has that same group, which makes the query return 30 duplicates per objectpermission totalling 9810 permissionobjects. The fix caused a load of the rack page with 50 objects per page to decrease from 1400 ms to 600 ms. I'm not sure how to fix it in a smart way, as I have a hard time seing how the relationship is supposed to work. Even the original query is iffy I think, as I'm pretty sure it can return duplicate permissions as well if user bound objectpermissions are used. The fix just makes the postgres remove the duplicates, which fixes the performance regression when using AUTH_LDAP_FIND_GROUP_PERMS. The query time increase should be negligible even in extreme cases. Still someone should probably rework the queries. Note: While the fix is pretty straightforward and I can't see how it could mess anything up, I would appreciate if someone else could test it before deciding to merge. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-29 22:26:25 +01:00
adam closed this issue 2025-12-29 22:26:25 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#13265
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?