Project

General

Profile

Actions

Feature #7289

open

ACL who can add a host to hostgroup.

Added by Steve Traylen about 10 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Users, Roles and Permissions
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

With foreman 1.4 if a user had edit rights to a host due to a filter applied to a subset of hostgroups
they could

  • Move a host to any hostgroup via API
  • however when editing via web interface they were at least only
    presented with hosgroups to which they were enabled in filter.

With foreman 1.5 the first point is still true that via API a host can be put in any hostgroup
but also the drop down box contains all hostgroups so it's a bit more obvious.

Having set up a role like the following with 1.5.

Resource Permissions Search
hostgroup view_hostgroups, create_hostgroups, edit_hostgroups, destroy_hostgroups title = cvmfs or title ~ cvmfs/%
Host/managed view_hosts, create_hosts, destroy_hosts, console_hosts, build_hosts, edit_hosts, ipmi_boot, power_hosts, puppetrun_hosts hostgroup_title = cvmfs or hostgroup_title ~ cvmfs/%

You also get the slightly bizare consequence that a user can edit a host in such a way that they then no longer
have access to it.

The RFE is to request to somehow control which hostgroups a user is permitted to put hosts in. Returning to old
1.4 behaviour where the drop down box was limited to hostgroups that can be viewed would also be good.


Related issues 4 (1 open3 closed)

Related to Foreman - Feature #4477: Improve permissions on resources in host creation/editing formClosedTomer Brisker02/27/2014Actions
Related to Foreman - Bug #14248: Unable to control where users can build hostsDuplicateTomer Brisker03/17/2016Actions
Related to Foreman - Bug #6760: Models should ensure the authorization of associated objects before associating them to the modelNew07/23/2014Actions
Has duplicate Foreman - Bug #12349: Filtering host groups does not work in the host creation screenDuplicate10/29/2015Actions
Actions #1

Updated by Dominic Cleal about 10 years ago

  • Related to Feature #4477: Improve permissions on resources in host creation/editing form added
Actions #2

Updated by Dominic Cleal about 10 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from RFE - ACL who can add a host to hostgroup. to ACL who can add a host to hostgroup.

#4477 and related bugs have some discussion about this, it's something we're beginning to look at across the application (associated resources).

Actions #3

Updated by Dominic Cleal about 9 years ago

  • Has duplicate Bug #12349: Filtering host groups does not work in the host creation screen added
Actions #4

Updated by Dominic Cleal over 8 years ago

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

Updated by Bryan Kearney over 8 years ago

  • Bugzilla link set to 1293716
Actions #6

Updated by Tomer Brisker over 8 years ago

  • Has duplicate deleted (Bug #14248: Unable to control where users can build hosts)
Actions #7

Updated by Tomer Brisker over 8 years ago

  • Related to Bug #14248: Unable to control where users can build hosts added
Actions #8

Updated by Marek Hulán over 8 years ago

  • Status changed from New to Duplicate

I believe this has been fixed by #4477 in 1.13.

Actions #9

Updated by Nacho Barrientos about 8 years ago

Hi,

Is the patch fixing this issue [0] preventing users from creating hosts via the API in the hostgroup of their choice no matter what are the roles assigned to the caller?

We haven't backported the patch yet to verify ourselves, but at a glance it does not seem to fix the issue described above by Steve.

[0] https://github.com/theforeman/foreman/commit/a4d69f8c15495ca8e9595f0f1503174e888f30b9

Actions #10

Updated by Dominic Cleal about 8 years ago

  • Status changed from Duplicate to New

I agree, #4477 only intended to improve the UI and doesn't enforce any permissions between objects, including hosts within host groups.

Actions #11

Updated by Marek Hulán about 8 years ago

Ok, I thought it returned the described 1.4 behavior. So if I understand you correctly, to fix this issue we need to add permissions checking for hostgroups being assigned to host. Is it desirable to control it via view_hostgroup permission or create_host permission?

EDIT: or even new host group permission called "assign_to_host"?

Actions #12

Updated by Dominic Cleal about 8 years ago

The description describes both - #4477 does restore the 1.4 UI-hiding behaviour, but overall control for both API and UI is preferred, so it's worth leaving this open. There's some overlap with #6760 as host/host groups are a specific instance of model associations.

Actions #13

Updated by Marek Hulán about 8 years ago

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

Updated by Nacho Barrientos about 8 years ago

Any chance this gets some love anytime soon? Thanks :)

Actions

Also available in: Atom PDF