Project

General

Profile

Bug #9506

Filter with permission edit_config_groups is not actually limited by search expression

Added by Roland Leissl over 6 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Users, Roles and Permissions
Target version:
Difficulty:
medium
Triaged:
Bugzilla link:
Fixed in Releases:
Found in Releases:

Description

I try to restrict access to specific config groups for a specific user. The new role should be able to filter the available config groups through their names. Therefore this user should not be able to change production relevant config groups.
I would need to use this feature in a real world DevOps scenario.

- create a new role and add filter 1 for host class permissions.
- select items "edit_classes" for filter 1.
- create filter 2 with config group permissions.
- select items "view_config_groups" and "edit_config_groups" for filter 2.
- uncheck unlimited checkbox for filter 2.
- enter search expression into search textbox like "name != production-apache" for filter 2.
- associate the role with restricted user.
- create config group with a name like "production-apache"
- login with the restricted user.
- on the menu go to configure - config groups.

expected result -> the user should not be able to view or edit config groups with the string "production" in their names.
actual problem -> the user is allowed to view and edit all config groups, even ones with matching names to the exclusion search expression.

Thanks for your attention,
Roland


Related issues

Related to Foreman - Bug #10923: Permission behaviour not consistentNew2015-06-24

Associated revisions

Revision 6825f8de (diff)
Added by Marek Hulán over 6 years ago

Fixes #9506 - Add granular permissions to config groups

Revision 787d5795 (diff)
Added by Marek Hulán over 6 years ago

Fixes #9506 - Add granular permissions to config groups

(cherry picked from commit 6825f8de6debe3854e03d171f6de5b630bfc85b9)

History

#1 Updated by Thomas Kuther over 6 years ago

I can reproduce this on our local instance.

It seems like "Host class > edit_classes", which provides no search filter itself, causes this "all-or-nothing" condition.

If a role has that right, it can add/remove classes from config groups with a != matching search filter
(i.e. the filter is set to "name != production-apache-servers", and still, the role can fully edit that group)

Vice versa: if it doesn't have edit_classes, it cannot add/remove classes from a config group even the search filter should allow it.

I didn't have any chance to dive into the code yet. Is the missing piece maybe a search filter for edit_classes?

#2 Updated by The Foreman Bot over 6 years ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman/pull/2335 added
  • Pull request deleted ()

#3 Updated by Marek Hulán over 6 years ago

  • Assignee set to Marek Hulán

#4 Updated by Dominic Cleal over 6 years ago

  • Legacy Backlogs Release (now unused) set to 50

#5 Updated by Marek Hulán over 6 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#6 Updated by Dominic Cleal about 6 years ago

  • Related to Bug #10923: Permission behaviour not consistent added

#7 Updated by Shimon Shtein almost 6 years ago

  • Bugzilla link set to 1284475

Also available in: Atom PDF