Project

General

Profile

Feature #4477

Improve permissions on resources in host creation/editing form

Added by Marek Hulán about 5 years ago. Updated 11 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Tomer Brisker
Category:
Authorization
Target version:
1.13.0
Difficulty:
Triaged:
Bugzilla link:
1293716
Pull request:
https://github.com/theforeman/foreman/pull/3369
Team Backlog:
Fixed in Releases:
Found in Releases:

Description

We can limit resources that are displayed to the user in host form using new granular permission. Or we could allow resources based on used hostgroup.

Related issues

Related to Foreman - Feature #812: cant assign roles to groups, just to usersClosed2011-03-31
Related to Foreman - Feature #1652: Fix privacy for puppetclasses.New2012-05-26
Related to Foreman - Bug #6226: if only one option for required field on new host page (ex. installation media), then automatically select itNew2014-06-15
Related to Foreman - Bug #6760: Models should ensure the authorization of associated objects before associating them to the modelNew2014-07-23
Related to Foreman - Bug #1875: user restricted to compute resource(s) can create baremetal hostsNew2012-09-27
Related to Foreman - Feature #7289: ACL who can add a host to hostgroup.New2014-08-28
Related to Foreman - Bug #18042: Host Compute Resource field does not honor view permissionsNew2017-01-12
Has duplicate Foreman - Bug #6470: Hostgroup selection box does not honor create_hosts filterDuplicate2014-07-02
Has duplicate Foreman - Bug #14248: Unable to control where users can build hostsDuplicate2016-03-17

Associated revisions

Revision a4d69f8c (diff)
Added by Tomer Brisker almost 3 years ago

Fixes #4477 - Host[group] form only show authorized resources

Previously, most dropdowns in the host and hostgroup edit forms
displayed all of the existing resources, including some that a user may
not have been authorized to view.
This commit makes sure only authorized resources are displayed, with the
exception of the current resource - so that editing a host will not
cause changes to its current associations in case the user is not
allowed to see them. This also includes a refactoring of the code to
reduce duplication.
I have also included a change to `with_taxonomy_scope_override` that
allows its use for relations. This was not previously possible due to
the `.unscoped` which was used to remove the default scope and has been
replaced with `.unscope(:where => :taxonomy)` that only removes any
previous taxonomy scopes.

History

#1 Updated by Marek Hulán about 5 years ago

  • Related to Feature #812: cant assign roles to groups, just to users added

#2 Updated by Dominic Cleal about 5 years ago

The same applies to other resources like domains, subnets and realms which have associated smart proxies. In theory we can use .authorized and only show the proxies on the form which the user has access to, but in practice this means a user who has edit permissions on a domain but no rights to view the associated smart proxies might inadvertently unset or change the associated proxy.

Our forms need to be smarter about associations to other resources that the user doesn't have access to.

#3 Updated by Dominic Cleal about 5 years ago

#4 Updated by Dominic Cleal almost 5 years ago

  • Has duplicate Bug #6470: Hostgroup selection box does not honor create_hosts filter added

#5 Updated by Dominic Cleal almost 5 years ago

  • Related to Bug #6226: if only one option for required field on new host page (ex. installation media), then automatically select it added

#6 Updated by Bryan Kearney almost 5 years ago

  • Bugzilla link set to 1118312

#7 Updated by Dominic Cleal almost 5 years ago

  • Related to Bug #6760: Models should ensure the authorization of associated objects before associating them to the model added

#8 Updated by Dmitri Dolguikh almost 5 years ago

  • Related to Bug #1875: user restricted to compute resource(s) can create baremetal hosts added

#9 Updated by Dmitri Dolguikh almost 5 years ago

  • Status changed from New to Assigned
  • Assignee set to Dmitri Dolguikh
  • Target version set to 1.7.5

#10 Updated by Dmitri Dolguikh almost 5 years ago

  • Target version changed from 1.7.5 to 1.7.4

#11 Updated by Dominic Cleal over 4 years ago

  • Related to Feature #7289: ACL who can add a host to hostgroup. added

#12 Updated by Dmitri Dolguikh over 4 years ago

  • Target version deleted (1.7.4)

#13 Updated by Dmitri Dolguikh over 4 years ago

  • Status changed from Assigned to New

#14 Updated by Roy Williams almost 4 years ago

Once a host group is created it is not possible to change puppet classes from within the host group once hosts are associated to it. However it is possible to associate puppet classes from the Configure -> Puppet -> Puppet Classes tab and check box them so they will work. The other issue is it's not possible to populate parameter overrides since I receive the error "Validation failed: Taxonomy has already been taken"

#15 Updated by Marek Hulán almost 4 years ago

This does not seem related to this authorization issue. Please open a separate issue unless there's an existing one for the issue you have.

Edit (domcleal): #13620

#16 Updated by The Foreman Bot about 3 years ago

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

#17 Updated by Tomer Brisker about 3 years ago

  • Has duplicate Bug #14248: Unable to control where users can build hosts added

#18 Updated by Tomer Brisker about 3 years ago

  • Assignee changed from Dmitri Dolguikh to Tomer Brisker
  • Bugzilla link changed from 1118312 to 1293716

#19 Updated by Anonymous almost 3 years ago

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

#20 Updated by Dominic Cleal almost 3 years ago

  • Legacy Backlogs Release (now unused) set to 160

#21 Updated by Tomer Brisker over 2 years ago

  • Related to Bug #18042: Host Compute Resource field does not honor view permissions added

Also available in: Atom PDF